How is it possible it's not present in v5 ? 😲

How is it possible it's not present in v5 ? 😲

no idea. all i know is that when i tried running current v5, it didn't exhibit the behavior (unless i messed up somewhere along the line). note that the whole handling of stuff there has subtly changed in v5...so more as an accident than intention, i think, this problem went away (but now, closing a dropdown doesn't seem to set focus back to the dropdown toggle, which is a new and exciting problem...sigh)

I'm very surprise the v5 code follow the v4 code, it shouldn't have such difference, is it possible for you to list what changed between v4 and v5 ?

I'm very surprise the v5 code follow the v4 code, it shouldn't have such difference, is it possible for you to list what changed between v4 and v5 ?

incidentally, i just added the new unit test to the clean master here locally, and ran the tests ... and they all passed. will dig deeper into why v5 is unaffected...

[edit] unit test in v5: #28913

Thanks @patrickhlauke 👍 Let me know if you have any questions about the v5 code

Thanks @patrickhlauke 👍 Let me know if you have any questions about the v5 code

without digging too deeply, one change that seems relevant is that in dropdown.js in v4 on line 484 it triggers a "click" (which happens on keydown for ESC as well) whereas in v5 on the matching line 492 is does Dropdown._clearMenus() which, from what I can see, does all sorts of extra sanity checking.

and for reference, the new issue i found in v5 #28914

Hmm true, nice catch, I don't remember why we made that change 🤔

Hmm true, nice catch, I don't remember why we made that change 🤔

well, a real button already reacts to all the appropriate things like SPACE and ENTER to open the dropdown (by firing the click event), so unnecessary for that. this leaves keydown reaction when menu is already open, which can really only be cursor keys and esc (plus special cases where somebody stuck an input/textarea in the menu itself) ... so i guess this makes more sense.