WP Admin Menus/SubMenus Overlap in small screen

[turtlepod]

Hello,

did anyone know about this/ever experience this issue with wp-admin?
or maybe this is a known issue?

If wp-admin is displayed in browser with "short" height (not only narrow), when we open a sub menu, it will overlap (and practically go crazy all around).

here’s the screenshot in:
desktop (resized) firefox + chrome (latest version, win7)

windows tablet( hp stream 7 ), using firefox (latest, win 8.1 with bing)

I can’t reproduce it in android/other mobile, because i can't resize the screen/browser size.

tested with latest wp (4.2.2) clean install. no plugin activated, tested with default theme too.

how to reproduce this issue.

1. resize the browser to be as short/small as in the screenshot.
2. visit wp-admin
3. click hamburger icon in admin bar to reveal admin menus
4. click parent menus such as "appearance" menu to view the sub menus.

note:
if i make the browser taller, the menus works fine.

maybe because wp_is_mobile() ?
(since ff browser in windows tablet is detected as desktop browser (it's a full version of windows) and not touch screen, maybe that's why it's working fine on my android phone.

thanks.
David.

[turtlepod]

i change the user agent in firefox to:

Mozilla/5.0 (Android; Mobile; Touch; rv:22.0) Gecko/22.0 Firefox/22.0

and the problem is gone.
the menus is working fine.

this will make wordpress detect the browser as mobile and touch browser(?)

so i believe the problem happen because of screen size and browser type (wp is mobile / user agent detection) conflict in wp admin design.

[mrfuad2007]

i am facing this issue in full screen on Windows Chrome not in firefox , its really critical. but MAC chrome works fine.

i am using

WordPress 4.2.3 also noticed on 4.3 same issue

Windows 8.1 Chrome Version 45.0.2454.85 m

Dell Inspiron Core i5 , 17" Screen 1366 x 768

[SergeyBiryukov]

Replying to mrfuad2007:

i am facing this issue in full screen on Windows Chrome not in firefox , its really critical.

Your issue is actually #33199, see also a ​WP Tavern post for details and a workaround.

[mrfuad2007]

Oh my God, Thanks Sergey ..

Replying to SergeyBiryukov:

Replying to mrfuad2007:

i am facing this issue in full screen on Windows Chrome not in firefox , its really critical.

Your issue is actually #33199, see also a ​WP Tavern post for details and a workaround.

[afercia]

Thinking this should be investigated testing with real mobile devices. Going to remove the "accessibility" focus since it's more a general issue not specifically tied to accessibility.

[desrosj]

#47089 was marked as a duplicate.

[sabernhardt]

#54608 was marked as a duplicate.

[sabernhardt]

#54616 was marked as a duplicate.

[sabernhardt]

I added the accessibility keyword again. Even though the interface problem is more general, this can happen more often when using browser zoom or the on-screen keyboard.

[collieit]

I digt a bit in the issue.
I found out that

<ul class="wp-submenu wp-submenu-wrap" style=""></ul>

can get a melformed css. Looking like (-113px is an exemple)

Element {
    margin-top: -113px;
}

The margin-top is calculate. If you go deeper in the menu list the problem get worse.

I think this will be done via the js submenu close and open method. The calculation missmatched the realty exspecialy in cases with long submenues that hits the page end.

[chaion07]

Thanks @turtlepod for reporting this. We reviewed the ticket during a recent bug scrub session. Here's a summary of the feedback provided by the team:

1. The issue can be reproduced on 5.9.2
2. The issue seems to appear when you resize the window but when you reload then it seems to work just fine
3. There are cases though when the issue would still appear after the page has been loaded- as long as the window is small enough in terms of width and height. Opening the submenus would produce the issue.
4. Its more likely to happen with larger submenus (i.e. settings) or with multiple submenus open

@mehedi890 has volunteered to work on this. Thanks!

Props to @hilayt24, @mehedi890 & @markparnell

[webcommsat]

Really happy to find this ticket getting some attention in the scrub earlier. Thanks @chaion07 and everyone at the scrub. I can replicate the issues as reported in 5.9.2 and two earlier versions. I have experienced this issue for a long time when using a smaller window on handheld and tablet devices, and even when the page is reloaded. Thanks for moving this forward.

Replying to chaion07:

Thanks @turtlepod for reporting this. We reviewed the ticket during a recent bug scrub session. Here's a summary of the feedback provided by the team:

1. The issue can be reproduced on 5.9.2
2. The issue seems to appear when you resize the window but when you reload then it seems to work just fine
3. There are cases though when the issue would still appear after the page has been loaded- as long as the window is small enough in terms of width and height. Opening the submenus would produce the issue.
4. Its more likely to happen with larger submenus (i.e. settings) or with multiple submenus open

@mehedi890 has volunteered to work on this. Thanks!

Props to @hilayt24, @mehedi890 & @markparnell

Fixes # 32747

In this PR, Fix WP Admin Menu & Submenu overlap issue fix

how to reproduce this issue.

1. resize the browser to be as short/small as in the screenshot.
2. visit wp-admin
3. click the hamburger icon in the admin bar to reveal admin menus
4. click parent menus such as the "appearance" menu to view the sub-menus.

Fixes # 32747

In this PR, Fix WP Admin Menu & Submenu overlap issue fix

how to reproduce this issue.

1. resize the browser to be as short/small as in the screenshot.
2. visit wp-admin
3. click the hamburger icon in the admin bar to reveal admin menus
4. click parent menus such as the "appearance" menu to view the sub-menus.

Hi, @audrasjb
I opened this PR for this ticket 32747 and I could use some feedback if this is the correct way.
Thanks

[ryokuhi]

We reviewed this ticket today during the Accessibility Team's weekly bug-scrub.
The PR probably needs to be refreshed, as there are changes to the package-lock.json file which should not be included with the patch.
Still, I'm adding the needs-testing label to bring a few extra eyes on this ticket to see if it solves the issue.

[mehedi890]

Thanks, @ryokuhi for your feedback. I created a PR with package-lock.json that was my mistake. Later I created another [PR](​https://github.com/WordPress/wordpress-develop/pull/2455) which is currently open for this ticket

[ryokuhi]

This ticket was reviewed again today during the Accessibility Team's weekly bug-scrub.
While testing, @sabernhardt found a problem when the menu is expanded from auto-fold. To solve it, it's possible that the check should regard the body width instead of the window width.

[sabernhardt]

with patch: submenus can hide under the bottom of the window at certain widths

[sabernhardt]

It's not the auto-fold. In the range of 783 to about 800 pixels, if the window height is short enough to add a scrollbar, the lower submenus do not adjust to avoid the bottom of the window.

(​the wp-menu-scrollbar video is also viewable on YouTube)

In Firefox's responsive mode, it works fine. The scrollbar width does not seem to have any effect there.

[sabernhardt]

I think it needs body width instead of $window.width(), but there could be another quirk right at the breakpoint due to the scroll bar (perhaps requiring a special condition).

[ironprogrammer]

Test Report

Patch tested: ​https://github.com/WordPress/wordpress-develop/pull/2455.diff

Environment

• Hardware: MacBook Pro Apple M1 Pro
• OS: macOS 12.6
• Browser: Safari 16.0, Google Chrome 105.0.5195.125, Mozilla Firefox 104.0.2
• Server: nginx/1.23.1
• PHP: 7.4.30
• WordPress: 6.1-beta1-54282-src

Actual Results

• ✅ Issue resolved with patch.

Additional Information

• Unable to reproduce reported issue in Safari.

Supplemental Artifacts

Before patch: Negative margin causes submenu (<ul>) to overlap menu header. Initially, header appears on top of menu, then hidden below it once submenu is interacted with. (Shown here, initial state.)

Chrome	Firefox

After patch: Submenu appears directly below menu heading, as expected. Above 782px, negative margin continues to position menu in viewport.

Under 783px Width	Over 782px Width

[ironprogrammer]

Replying to sabernhardt:

I think it needs body width instead of $window.width(), but there could be another quirk right at the breakpoint due to the scroll bar (perhaps requiring a special condition).

Would you please provide additional information regarding the "quirks" that have been noted? Such as OS/browser, specific dimensions, etc? That would be a great addition for the testing steps. Thanks!

[sabernhardt]

sub-menu expanded in Firefox at 788 pixels wide

[sabernhardt]

I should have mentioned earlier that I was using Firefox and Edge on Windows.

The patch generally helps, but it might be worse under specific conditions.

How to Meet the Odd Conditions

1. Apply the patch. (I had trouble with NPM today, so I made the change directly in common.js, in a WordPress 6.1 Beta 1 installation.)
2. Go to the Admin Dashboard, and open Screen options to hide all widgets except for "At A Glance" so the side menu is taller than the page content.
3. Shrink the window width until the dashboard widget is in one column but the auto-folded menu is still visible on the side. The window width would be 783 to 799 pixels at default 100% zoom.
4. Shrink the window height until the scrollbar appears.
5. If using a mouse, hover the cursor over the Tools or Settings icon link to expand the sub-menu. The scrollbar will show that the page height is taller now, and some links are beyond the window height.
6. Move the cursor over the expanded sub-menu. I was able to scroll down with the mouse wheel—and likewise with the Page Down key—while the cursor was still over the sub-menu. However, if anyone wants/needs to drag the scrollbar to view links beyond the window, moving the cursor away from the menu will collapse the sub-menu automatically. Also, when using the Tab key to navigate the menu, I needed to use the Page Down key (or down arrow) after every time I pressed Tab to see the focused link.
7. Now move the cursor to another link in the side menu, and then return the cursor over the same icon link. In Firefox, the sub-menu expanded as expected. But Chrome and Edge got stuck in a recalculating loop and made the screen flicker with and without the sub-menu.

Environment

Hardware: HP Laptop 15-da0xxx
OS: Windows 10
Browsers: Mozilla Firefox 105.0.1, Google Chrome 105.0.5195.127, Microsoft Edge 105.0.1343.50
PHP: 7.4 (WampServer)
WordPress: 6.1-beta1-54282-src

I think it's related to a discrepancy between the JS measurement and CSS breakpoint when the scrollbar appears, but the CSS has a 799px/800px breakpoint.

[sabernhardt]

Simply editing $window to $('body') does not fix it.

[sabernhardt]

Checking whether the menu toggle button is showing seems to work in the odd cases:

if ( adjustment > 1 && $('#wp-admin-bar-menu-toggle').is(':hidden') ) {
	$submenu.css( 'margin-top', '-' + adjustment + 'px' );
} else {
	$submenu.css( 'margin-top', '' );
}

[sabernhardt]

checks whether toolbar mobile menu toggle is showing or not

[sabernhardt]

I also tried if ( adjustment > 1 && ! $wpwrap.hasClass( 'wp-responsive-open' ) ). However, the class does not update when resizing the window, so that is less reliable.

Technically someone can remove/replace the #wp-admin-bar-menu-toggle element or show/hide it at different screen sizes.

• When I removed the toggle and hovered over links, I did not get console errors. It still might be worth checking that the toggle exists.
• If someone changes the breakpoint, updating quite a lot of CSS, the window width would not help in that case any more than checking the toggle state. (I had considered using it as a fallback for the other: if ( adjustment > 1 && ( $('#wp-admin-bar-menu-toggle').is(':hidden') || $window.width() > 782 ) ).)

[ironprogrammer]

Thanks for the additional detail, @sabernhardt!

Test Report

Patch tested (via @sabernhardt): https://core.trac.wordpress.org/attachment/ticket/32747/32747.diff -- 👍🏻 on macOS
Windows testing still needed.

Environment

Hardware: MacBook Pro Apple M1 Pro
OS: macOS 12.6
Browser: Safari 16.0, Google Chrome 105.0.5195.125, Mozilla Firefox 105.0.1
Server: nginx/1.23.1
PHP: 7.4.30
WordPress: 6.1-beta2-54337-src

Actual Results

✅ Originally reported issue (<783px browser width) resolved with patch.
⚠️ In macOS + Firefox, unable to replicate issue described in comment:37 (>782px browser width), as scrollbar does not occupy window width on macOS. Patch needs additional validation in a Windows environment.

Additional Information

Unable to reproduce reported issue in Safari.

[costdev]

Test Report

Patch tested: https://core.trac.wordpress.org/attachment/ticket/32747/32747.diff

Environment

• OS: Windows 10
• Server: Apache (Linux)
• Browser: Firefox 105.0
• WordPress: 6.1-beta2-54337-src
• Theme: Twenty Twenty-Two
• Plugins: None activated

Actual Results

• ❌ Without patch: Bug reproduced on 437px * 317px.
• ✅ With patch: The issue is resolved.
• ✅ When the menu is a collapsed (icons-only), sub-menus appear within the viewport, rather than extending outside of it.

[ugyensupport]

@chaion07 Great thanks I could also reproduce the issue on 5.9.2.

Environment:
Hardware: MacBook Air Apple M1 Pro
OS: macOS 11.6.7
Browser: Safari 16.0, Google Chrome 105.0.5195.125, Mozilla Firefox 105.0.1
Server: Nginx/1.23.1
PHP: 8
WordPress: 6.1-beta2-54337-src

It looks good on my end.

[audrasjb]

Thanks @sabernhardt for the detailed testing instructions.
Now I can reproduce the exact issue and I can confirm it's solved on my side with 32747.diff.

[audrasjb]

before patch

[audrasjb]

after patch: works fine

[audrasjb]

In 54392:

Administration: Avoid menu/sub-menu overlap on small screens.

This changeset fixes overlapping glitches discovered in WordPress Admin menu behavior when used on small screens.

Props turtlepod, collieit, chaion07, hilayt24, mehedi890, markparnell, webcommsat, mehedi890, ryokuhi, sabernhardt, ironprogrammer, audrasjb, costdev, ugyensupport.
Fixes #32747.