Problem/Motivation
Follow-up from
Olivero has 'main' and 'secondary' menus, the obvious choice is to put the 'navigation' menu in main and 'user account' menu in secondary.
When you have between 4-6 items in the main menu (not that many), a couple of items in the secondary menu (also not that many), and a 13" laptop monitor, it doesn't look great.
Opening as major since this is quite visually jarring right at the top of the page, and seems like an easy situation to get into, but could equally be 'normal'.
The previous approach to long menus in #3186992: Nav menu items can overflow outside of container , didn't look at the situation when there's something in the secondary menu, and that makes the situation worse - especially since word wrapping often means there's a lot of whitespace between the wrapped main menu and the secondary.
Steps to reproduce
Enable olivero and add several items to the navigation menu.

Proposed resolution
Not really my area, but a couple of ideas:
1. Change CSS/markup so that the secondary menu as a whole wraps under the main menu (but maybe still floated to the right) if things are too wide. If the navigation menu is still too wide even then, it would have to wrap to two lines too.
2. Javascript black magic to switch to the burger menu, even on desktop, if the main or secondary menu wraps.
From original report: Here is an example, reducing the window in width. When one of the menu links touches the logo area + no, it automatically switches to mobile mode :
Remaining tasks
User interface changes
API changes
Data model changes
Release notes snippet


| Comment | File | Size | Author |
|---|---|---|---|
| #32 | 3246755-32-10.0.x-test-only-FAIL.patch | 1.79 KB | mherchel |
| #32 | 3246755-32-10.0.x.patch | 7.72 KB | mherchel |
| #29 | lessMenus.png | 51.44 KB | libbna |
| #29 | desktop.png | 72.12 KB | libbna |
| #26 | 3246755-26.patch | 7.82 KB | mherchel |
Comments
Comment #2
mherchelI've been thinking about things like this for a bit. We could use something like resize observer to dynamically do this. However, doing so might be confusing for editors as they might not know why the site has mobile navigation.
Comment #3
zenimagine commentedThis mode should be activated manually from the theme's preferences with some explanation. I find it less confusing than navigation on 2 lines
Comment #4
mherchelThere's already an option to enable the mobile menu at all widths. How would this be different?
Comment #5
zenimagine commentedThe option activates the mobile menu on all widths. I just want to activate it if the menu overflows with an option besides the one that already exists.
I want to keep my menu on widescreen, unless there is an overflow.
It would take a parameter for "If the main menu overflows":
"Display on 2 lines" OR "Switch to the mobile menu".
Comment #6
catchI just opened a duplicate of this at #3275440: Olivero main/user account menu layout struggles with long menus, recategorising as a bug since IMO this is a bit more of an obvious problem once you add a secondary menu and updating the issue summary with more details.
Comment #7
catchComment #8
mherchelHere's a patch that uses resize observer to watch for the change in format, and once detected it switches to the mobile menu.
It works pretty well, but won't support IE11 (which is probably okay).
Comment #9
yogeshmpawarFixed CS issues.
Comment #10
libbna commentedReviewed #9 patch and this is how it is looking. Added desktop and laptop view images.
Is this how it should look like? I don't see any changes, please correct me if I am wrong.
Comment #11
libbna commentedI also reviewed #8 patch and it is giving an expected result.
After adding 7 menu items, hamburger icon is visible. and if there are 6 or less menu items then all the menus can be seen in one line.
Added screen shots.
Comment #12
libbna commentedComment #13
mherchelThanks for the feedback! Setting back to Needs Work because we still need tests. If anyone else wants to do additional manual testing (especially on other browsers), please do so.
Comment #14
mherchelComment #15
mherchelLooks like the test isn't passing.
Comment #16
mherchelReady for review!
Comment #17
mherchelComment #18
libbna commentedHi @mherchel This needs work or review?
Comment #19
mherchel@Libbna Back to needs work. The tests are failing, plus I think there can be some additional optimizations.
Comment #20
libbna commentedokay.
Comment #21
mherchelUpdated patch with (hopefully) fixed tests
Comment #24
libbna commentedReviewed patch #21 and it is successfully working.
Added screenshots - before patch and after patch.
Comment #25
mherchelI did a bit of refactoring of this:
Setting this back to needs review because of the changes. Thank you!
Comment #26
mherchelForgot to change a variable name. New patch (and interdiff) attached.
Comment #28
mherchelUnrelated failure. Re-queuing tests.
Comment #29
libbna commentedI have reviewed in every aspect and #26 patch looks good to me.
Only I didn't get this point
.
How can I test to prove this point?
Comment #30
cindytwilliams commentedI also reviewed this patch, and it looks good to me, including this part:
Before patch:
After patch:
Marking RTBC+1
Comment #31
mherchelPatch for 10.0.x attached. Same patch except no need to check for ResizeObserver.
Comment #32
mherchelApparently Nightwatch's
resizeWindow()command straight up doesn't work in Drupal 10. It works fine in Drupal 9.4.x. Maybe different yarn dependencies? 🤷♂️🤷♂️🤷♂️I'm attaching a new patch for Drupal 10 that replaces
resizeWindow()withsetWindowSize(), which does the same thing.Comment #33
mherchelLooks like @nod_ ran into the same
resizeWindow()issue in #3265617: Update Nightwatch to 2.x at https://www.drupal.org/project/drupal/issues/3265617#mr1958-note82049Anywho, the 10.0.x patch above should be good to go (assuming tests pass 🤞🤞🤞)
Comment #40
lauriiiCommitted 0790449 and pushed to 10.0.x. Also committed #26 to 9.5.x and cherry-picked to 9.4.x. Thanks!