Regression with Menus and 0.4.0 about ariakit HOT 21 CLOSED

Steps to reproduce the bug

Have a Menu set, and showOnHover={true}

I couldn't see any difference between 0.3.13 and 0.4.0 when using showOnHover. Could you please provide more details?

from ariakit.

The behavior I see is that show and hide work, but the hide is delayed, so I see two up at the same time.

In my environment, calling hide() delays it by a bit. It used to be show / hide with 0 delay.

https://codesandbox.io/p/sandbox/ariakit-forked-mqm56w?file=%2Fmenu-b.js%3A15%2C26

    const rkMenu = useMenuStore({
      showTimeout: 4000,
      hideTimeout: 5100,
    });

on the MenuButton I do:
                  onMouseEnter: () => {
                    rkMenu.show();
                  }
                  onMouseLeave: () => rkMenu.hide(),

from ariakit.

What exactly is the difference between versions 0.3.13 and 0.4.0 in that CodeSandbox? I ran tests with both versions and they seem to behave identically. I can keep both menus open if I move the mouse in a specific way in both versions. The video below is using your CodeSandbox with @ariakit/[email protected]:

from ariakit.

Is it possible that the behavior you're observing with 0.4.0 was present earlier, but you just didn't happen to reproduce it (since it requires specific mouse movements)?

The demo you provided is working as expected, for both 0.3.13 and 0.4.0, due to hover intent. When the user moves the mouse toward the menu, pointer events outside the menu are disabled. That's why your onMouseLeave event handler doesn't trigger when the mouse leaves the menu button to reach its menu. Without this hover intent detection, it wouldn't work as you expect at all. You can turn off the hover intent detection feature by setting the disablePointerEventsOnApproach prop to false on the Menu component.

from ariakit.

I tried disablePointerEventsOnApproach Ill keep fiddling, but it worked great in 0.3 and as soon as I go to 0.4 I See:

from ariakit.

Is the app public (not the code, just the app itself)?

from ariakit.

Unfortunately no. I am just fiddling away trying to see why the timeouts don't work right. I really want the top level site menus to be up and down immediately, and have the rest of them have a nice natural timeout. I do this in a store action where I knock them down:

    actionHideAllMenusAndShowMenu: menuToShow => {
      const menus = get().topLevelMenus;
      menuToShow.setState('timeout', 0);
      menuToShow.setState('showTimeout', 0);
      menuToShow.show();
      menus.forEach(menu => {
        if (menu !== menuToShow) {
          menu.setState('hideTimeout', 0);
          console.log(menu.getState());

          menu.hide();
        }
      });
    },
    
    This worked swell in the old version.

from ariakit.

What I Am noticing is even if I set timeout: 0 on the store, the menus still (even the normal second level menus) lag and overlap. If I revert to 0.3, I can change the timeouts and it responds as I expect. It's like somehow the timeout isn't really being honored internally.

from ariakit.

Are those menus animated?

from ariakit.

nope - never had animation on. I just flipped animation on - in 0.3 - and it starts to do the same thing....

from ariakit.

WOO! That was it! If I do 0.4 and set animated to 0, it works fine!!!

I just upgraded and noticed the deprecation warning about the animated store prop when I go to 0.4.0...

from ariakit.

In v0.4.0, animations are automatically detected. Is there a chance you have any CSS animation/transition property set on your menu components? Can you inspect them and check their computed styles?

from ariakit.

Does this count as an animation?

from ariakit.

Yes, Ariakit will now automatically wait for those 300 milliseconds before hiding the menu, the same way it would do with the animated prop set to true in previous versions. You can turn off the leave transition with something like this:

.menu[data-leave] {
  transition: none;
}

from ariakit.

so not with animated: false? Big thanks again @diegohaz

from ariakit.

so not with animated: false? Big thanks again @diegohaz

Exactly. Though that works now, the animated prop will be removed in a future version (probably hard deprecated in 0.5.0 and then finally removed in 0.6.0 or 1.0.0), so transitions should be managed where they should be, in CSS.

from ariakit.

Whew I think I Am going to limp off by doing animated: false on my stores at the moment, and get that in and working. This was a surprise for sure and super hard to tell!

from ariakit.

I don't see the [data-leave] attribute on the menu - ?

          <AriaMenu
            store={rkMenu}
            render={
              <Paper
                component="ul"
                sx={{
                  zIndex: 15000,
                  m: 0,
                  p: 0,
                  ':focus-visible': { outline: 'none' },
                  '[data-leave]': {
                    transition: 'none',
                  },
                }}
                elevation={8}
              />
            }

from ariakit.

Ok for other folks - I am integrating MUI and Ariakit. This is an unfriendly combination given how much MUI does these transitions all over the css.

My current fix is to do an sx prop way up at the top of the component that houses our menus and do this:

          '* [data-leave]': {
            transition: 'unset!important',
          },

from ariakit.

@diegohaz Diego - just one last point - super strange here.
I have one menu that renders in a portal and portalRef and one that doesn't.

The one that renders in the Portal, the LAST MENU onClicks won't work if I do the [data-leave] css trick, the rest work fine. The CSS somehow stops the onClick handler. I have it absolutely pegged.

The one that doesn't render in the portal, works fine with the [data-leave] transition unset.

from ariakit.

@diegohaz Diego - just one last point - super strange here.

I have one menu that renders in a portal and portalRef and one that doesn't.

The one that renders in the Portal, the LAST MENU onClicks won't work if I do the [data-leave] css trick, the rest work fine. The CSS somehow stops the onClick handler. I have it absolutely pegged.

The one that doesn't render in the portal, works fine with the [data-leave] transition unset.

That looks like another problem. Could you open a separate issue (with a repro please, even if it's not minimal)?

from ariakit.