Nav dropdown closes when a smaller/shorter 3rd level dropdown is expanded

[aslaymoore]

Problem/Motivation

The navigation dropdown menu closes when you open a 3rd level menu that is shorter than the previous state/height of the dropdown menu. This makes it harder to browse menu items to find the page you're looking for, and forces you to open the dropdown multiple times.

Describe the bug

When a 3rd level menu is expanded that is shorter than the previously opened 3rd level menu, the overall height of the dropdown menu shrinks. The change in height leads to your mouse being outside of the dropdown menu (outside of hover/focus target), which subsequently causes the dropdown menu to close.

Example:

Nav item A
   - Dropdown item A1
   - Dropdown item A2
      - Sub-item a
      - Sub-item b
      - Sub-item c
      - Sub-item d
      - Sub-item e
      - Sub-item f
   - Dropdown item A3
Nav item B
Nav item C
   - Dropdown item C1
   - Dropdown item C2
   - Dropdown item C3
      - Sub-item a
      - Sub-item b
      - Sub-item c
Nav item D

Dropdown item A2 has 6 dropdown items, whereas Dropdown item C3 only has 3 items. If I expand Dropdown item A2 and then try to expand Dropdown item C3, the entire dropdown menu closes before I have a chance to do anything, because the height of the dropdown menu with Dropdown item C3 expanded is less than that of the dropdown menu with Dropdown item A2 expanded.

To Reproduce

1. Visit https://marcom.arizona.edu/brand-guidelines
2. Expand the "Brand Guidelines" menu item
3. Expand the "Logos" dropdown item
4. With the menu still open, move your mouse to the "Rights & Releases" dropdown item and expand it.
5. Observe the dropdown menu close.

Proposed resolution

Prevent premature closing of the dropdown menu when 3rd level menu items are expanded and collapsed.

Expected behavior

Dropdown menu should remain active/open when dropdown menu hight changes due to expansion/collapse of 3rd level menu items.

Screen recording

Screen.Recording.2026-03-23.at.2.59.04.PM.mov

[camikazegreen]

For expected behavior, would you expect a longer delay before close, or would you expect to have to click somewhere else to close the dropdown?

[danahertzberg]

I agree this can be cumbersome. @aslaymoore What would you expect to happen?

We do have the ability to click the first arrow that opens the menu to make it stay open regardless of the hover state. So that can help if someone clicks.

@BradBarkel @elyssanaval @ewlyman @natebyerley Can you provide some input on this issue as well? When a third level menu is shorter than a previously opened third level menu, the whole menu closes because the menu shrinks off the hover area. Is this just determined to be "wonky" and not common? Or is there something we should do to fix this issue?

[ewlyman]

@danahertzberg

There's inconsistent behavior between Level 1->Level 2 behavior and Level 2->Level 3 behavior which is, I think the root cause of confusion. It's important to note, however, that this inconsistent behavior does not occur on touch screens.

On a non-touch screen laptop or desktop the Level 2 menu will open with either a click on the drop down icon or by hovering the cursor over it.

• If the Level 2 menu was opened by clicking on the icon, the Level 3 menu must be opened the same way (clicking on an icon) and the Level 2 menu will remain in place on screen.
• If the Level 2 menu was opened by hovering over the icon, the level 3 menu still must be opened by clicking on an icon. If Level 3 is opened to a longer and then shorter menu, the hover stops working and the Level 2 menu collapses.

On a touch screen laptop or tablet, however, no hovering is possible. So both Level 2 and Level 3 are opened by clicking their respective icons. The "disappearing Level 2" issue doesn't occur, because the appear-on-hover function for Level 2 was never invoked.

Off the top of my head, I can't think of any HCI study or Nielsen-Norman research that gives us a definitive "this is better" decision. And I had no part of the original "open on hover vs. touch/click" conversations.

My first thought, though, is that end users would prefer menu behavior to be consistent across devices/interfaces of approximately similar sizes, such as laptop screens and tablets (phones are usually expected to behave differently). Which would mean seriously reconsidering the "open on hover" behavior for non-touch screens.

[aslaymoore]

I think this is just one of the symptoms of switching from a click triggered dropdown to a hover triggered dropdown that also has a 3rd level to interact with, since it relies completely on mouse positioning (for mouse users).

For expected behavior, would you expect a longer delay before close, or would you expect to have to click somewhere else to close the dropdown?

Given that the dropdown opens on hover, having to click somewhere else to dismiss the dropdown would be unexpected and confusing behavior. If the navbar were still click activated, clicking elsewhere to dismiss it would be more expected. So I don't think this would be a good option with the current implementation.

I also don't think that lengthening the delay before close would be great either. This would cause the dropdown menu to remain open when a user intentionally removes their mouse from the dropdown. Or it could also leave a dropdown open when the user switches to a different dropdown menu (you might end up with 2+ dropdowns open at the same time, before the "oldest" one eventually dismisses).

Even if we allowed multiple sub-menus to be expanded at the same time, you would end up with the same problem, if the user ever collapsed a sub-menu towards the bottom of the dropdown. So I don't know that there's really a good solution to this problem when the dropdown relies on the mouse to be focused within/hovered on the dropdown to remain active.

What would you expect to happen?

At the end of the day, I just don't want the dropdown closing prematurely when users are trying to browse the menus. It gets frustrating pretty quickly when something as prominent as the main navigation is difficult to use (I experienced this frustration myself while trying to find specific information on the Brand website). Maybe the only way to prevent that is going back to a click activated dropdown? I'm not really sure what the best path is here...

We do have the ability to click the first arrow that opens the menu to make it stay open regardless of the hover state. So that can help if someone clicks.

I don't think this would be an obvious enough workaround for the standard user; if they hover on the arrow and a dropdown appears, it's more likely they will immediately move to the dropdown menu to browse and find what they're looking for, rather than clicking on the arrow prior to moving their mouse to the dropdown.

[danahertzberg]

Thanks everyone! Seems like I can connect with @tkmccarthy in marketing to discuss removal of the hover functionality (leaving only the click functionality). If that's not doable, I will close this issue as "not planned".

[danahertzberg]

After emailing with Tom. We are going to have @BradBarkel look into more UX best practices and make a recommendation to Tom if any changes seem necessary from a usability perspective.