#32747 closed defect (bug) (fixed)
WP Admin Menus/SubMenus Overlap in small screen
Reported by: | turtlepod | Owned by: | audrasjb |
---|---|---|---|
Milestone: | 6.1 | Priority: | normal |
Severity: | normal | Version: | 4.2.2 |
Component: | Administration | Keywords: | has-patch has-testing-info commit |
Focuses: | ui, accessibility, javascript | Cc: |
Description
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.
- resize the browser to be as short/small as in the screenshot.
- visit wp-admin
- click hamburger icon in admin bar to reveal admin menus
- 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.
Attachments (7)
Change History (60)
#2
follow-up:
↓ 3
@
9 years ago
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
#3
in reply to:
↑ 2
;
follow-up:
↓ 4
@
9 years ago
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.
#4
in reply to:
↑ 3
@
9 years ago
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.
This ticket was mentioned in Slack in #accessibility by afercia. View the logs.
8 years ago
#6
@
8 years ago
- Focuses accessibility removed
- Keywords needs-testing added
- Milestone changed from Awaiting Review to Future Release
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.
#10
@
3 years ago
- Component changed from Menus to Administration
- Focuses accessibility css added
- Keywords needs-patch added; needs-testing removed
- Milestone changed from Future Release to 6.0
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.
This ticket was mentioned in Slack in #core by maksimkuzmin. View the logs.
3 years ago
#12
@
3 years ago
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.
This ticket was mentioned in Slack in #core by chaion07. View the logs.
3 years ago
This ticket was mentioned in Slack in #core by chaion07. View the logs.
3 years ago
#15
follow-up:
↓ 16
@
3 years ago
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:
- The issue can be reproduced on 5.9.2
- The issue seems to appear when you resize the window but when you reload then it seems to work just fine
- 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.
- 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
#16
in reply to:
↑ 15
@
3 years ago
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:
- The issue can be reproduced on 5.9.2
- The issue seems to appear when you resize the window but when you reload then it seems to work just fine
- 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.
- 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
This ticket was mentioned in PR #2451 on WordPress/wordpress-develop by mehedifoysal.
3 years ago
#17
- Keywords has-patch added; needs-patch removed
Fixes # 32747
In this PR, Fix WP Admin Menu & Submenu overlap issue fix
how to reproduce this issue.
- resize the browser to be as short/small as in the screenshot.
- visit wp-admin
- click the hamburger icon in the admin bar to reveal admin menus
- click parent menus such as the "appearance" menu to view the sub-menus.
This ticket was mentioned in PR #2455 on WordPress/wordpress-develop by mehedifoysal.
3 years ago
#18
Fixes # 32747
In this PR, Fix WP Admin Menu & Submenu overlap issue fix
how to reproduce this issue.
- resize the browser to be as short/small as in the screenshot.
- visit wp-admin
- click the hamburger icon in the admin bar to reveal admin menus
- click parent menus such as the "appearance" menu to view the sub-menus.
mehedifoysal commented on PR #2455:
3 years ago
#19
Hi, @audrasjb
I opened this PR for this ticket 32747 and I could use some feedback if this is the correct way.
Thanks
This ticket was mentioned in Slack in #accessibility by ryokuhi. View the logs.
3 years ago
#21
@
3 years ago
- Keywords needs-testing added
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.
This ticket was mentioned in Slack in #core by chaion07. View the logs.
3 years ago
#23
@
3 years ago
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
This ticket was mentioned in Slack in #accessibility by ryokuhi. View the logs.
3 years ago
#25
@
3 years ago
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.
#26
@
3 years ago
- Focuses javascript added; css removed
- Keywords needs-refresh added; needs-testing removed
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.
This ticket was mentioned in Slack in #accessibility by ryokuhi. View the logs.
2 years ago
This ticket was mentioned in Slack in #accessibility by ryokuhi. View the logs.
2 years ago
This ticket was mentioned in Slack in #accessibility by chaion07. View the logs.
2 years ago
#31
follow-up:
↓ 36
@
2 years ago
- Keywords changes-requested added; needs-refresh removed
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).
This ticket was mentioned in Slack in #core by audrasjb. View the logs.
2 years ago
This ticket was mentioned in Slack in #accessibility by sabernhardt. View the logs.
2 years ago
This ticket was mentioned in Slack in #accessibility by joedolson. View the logs.
2 years ago
#35
@
2 years ago
- Keywords has-testing-info added
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 |
---|---|
#36
in reply to:
↑ 31
@
2 years ago
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!
#37
@
2 years ago
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
- 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.)
- 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.
- 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.
- Shrink the window height until the scrollbar appears.
- 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.
- 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.
- 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.
#39
@
2 years ago
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', '' ); }
#40
@
2 years ago
- Keywords needs-testing added; changes-requested removed
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 ) )
.)
This ticket was mentioned in Slack in #core by audrasjb. View the logs.
2 years ago
This ticket was mentioned in Slack in #core-test by sabernhardt. View the logs.
2 years ago
#43
@
2 years ago
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.
#44
@
2 years ago
- Keywords needs-testing removed
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.
This ticket was mentioned in Slack in #core-test by ironprogrammer. View the logs.
2 years ago
This ticket was mentioned in Slack in #accessibility by sabernhardt. View the logs.
2 years ago
#47
@
2 years ago
@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.
This ticket was mentioned in Slack in #accessibility by abhanonstopnews. View the logs.
2 years ago
This ticket was mentioned in Slack in #accessibility by abhanonstopnews. View the logs.
2 years ago
#50
@
2 years ago
- Owner set to audrasjb
- Status changed from new to accepted
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
.
i change the user agent in firefox to:
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.