Polish and fix regressions in the new menu components.
Review Request #10936 — Created March 3, 2020 and submitted
RB.MenuViewcomponent had a few design decisions
made early on that, upon further reflection, weren't really necessary,
and impacted other parts of the UI.
display: block/noneto control visibility, for a couple
reasons that made sense earlier in development, but weren't ultimately
displaycannot be animated, and affected animations, it
was up to
RB.MenuViewto more closely manage the opening/closing
states, adding some JS-specific intermediary classes to turn
on/off at the right times. This actually broke the legacy
which broke opening review request action menus.
Addressing this was actually pretty easy, and allowed for the deletion
of a lot of code. We're now once again using
to fully manage the display. The JS intermediary state classes are now
gone, and all the
RB.MenuVieware gone as well.
This also allowed
It also fixes an issue with the key bindings. Previously,
captured all keyboard events, with the idea being that while you're
interacting with a menu, you shouldn't be triggering other elements
accidentally. That ended up not working as well in practice. This
prevented things like jumping to another part of the UI via a keyboard
shortcut (posing an accessibility issue), or even reloading the page.
It no longer swallows all events, only preventing default behavior and
bubbling if the event is being specifically handled by the menu.
Unit tests pass.
Tested both mouse-based and keyboard-based navigation and usage of the
menu. Verified that keyboard-based navigation didn't animate the menu
(ensuring that capability hasn't broken).
Tested that the review request action menus worked.
This needs to have "Returns:" now.