Fix navbar dropdown behavior

[kammeows]

Fixes #3394

Changes:

I have simply removed the onMouseOver function in Menubar to prevent auto-opening.

I have verified that this pull request:

• has no linting errors (npm run lint)
• has no test errors (npm run test)
• is from a uniquely-named feature branch and is up to date with the develop branch.
• is descriptively named and links to an issue number, i.e. Fixes #123

[raclim]

Thanks so much for your work on this and for explaining the issue so thoroughly! After giving this some thought, I think having the dropdown not be visible on hover unless a user intentionally wants to focus on it makes sense to me.

I'm going to merge this in—@tespin feel free to let me know if there might be some context I might be missing here!

[tespin]

hi all! historically, the expected hover behavior for menubars containing dropdown menus is that they do open on hover -- you'll see this if you open up something like google sheets and hover over that menubar. you can also turn to the menubar of your browser (where it says "File", "Edit", etc) for a more immediate example. the limitation is that the open-on-hover behavior should only fire if a dropdown menu is already focused and open.

the wai-aria guidelines don't prescribe a behavior one way or the other, but they do lay out some success criteria for cases like ours where content does appear on hover. basically they just say that if hover causes any content changes, the interaction should be predictable. since open-on-hover is widely implemented, i would opt towards leaving it in.

the issue of requiring a second click to open a new submenu, however, is problematic, and does get addressed in #3320 ! i've been caught up at work but i am hoping to push that out relatively soon.

[raclim]

Ohhh I see, thanks so much for the additional context @tespin! In that case I might revert this PR then!

I'm sorry that we couldn't get this one in @kammeows but thanks so much again for looking into this and giving it a shot!