Make WordPress Core

Opened 8 years ago

Closed 8 months ago

Last modified 8 months ago

#32747 closed defect (bug) (fixed)

WP Admin Menus/SubMenus Overlap in small screen

Reported by: turtlepod's profile turtlepod Owned by: audrasjb's profile 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)

https://dl.dropboxusercontent.com/u/32880842/etc4/wp-admin-small-firefox-chrome.jpg

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

https://dl.dropboxusercontent.com/u/32880842/etc4/wp-admin-stream-ff.jpg

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.

Attachments (7)

wp-admin-small-firefox-chrome.jpg (56.7 KB) - added by turtlepod 8 years ago.
wp-admin-stream-ff.jpg (147.3 KB) - added by turtlepod 8 years ago.
wp-menu-scrollbar.mp4 (357.1 KB) - added by sabernhardt 14 months ago.
with patch: submenus can hide under the bottom of the window at certain widths
Firefox-Windows-with-patch-788.png (52.2 KB) - added by sabernhardt 9 months ago.
sub-menu expanded in Firefox at 788 pixels wide
32747.diff (482 bytes) - added by sabernhardt 8 months ago.
checks whether toolbar mobile menu toggle is showing or not
Capture d’écran 2022-10-05 à 00.30.42.png (188.5 KB) - added by audrasjb 8 months ago.
before patch
376faa3ac97647048e31394341259eec.gif (399.4 KB) - added by audrasjb 8 months ago.
after patch: works fine

Download all attachments as: .zip

Change History (60)

#1 @turtlepod
8 years ago

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.

#2 follow-up: @mrfuad2007
8 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

http://s14.postimg.org/s21cvctwx/wordpress_bug.png

Last edited 8 years ago by mrfuad2007 (previous) (diff)

#3 in reply to: ↑ 2 ; follow-up: @SergeyBiryukov
8 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 @mrfuad2007
8 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.


7 years ago

#6 @afercia
7 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.

#7 @desrosj
4 years ago

#47089 was marked as a duplicate.

#8 @sabernhardt
18 months ago

#54608 was marked as a duplicate.

#9 @sabernhardt
18 months ago

#54616 was marked as a duplicate.

#10 @sabernhardt
18 months 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.


18 months ago

#12 @collieit
15 months 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.


15 months ago

This ticket was mentioned in Slack in #core by chaion07. View the logs.


15 months ago

#15 follow-up: @chaion07
15 months 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:

  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

#16 in reply to: ↑ 15 @webcommsat
15 months 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:

  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

This ticket was mentioned in PR #2451 on WordPress/wordpress-develop by mehedifoysal.


15 months 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.

  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.

https://i0.wp.com/user-images.githubusercontent.com/52179233/159660790-c3a9a586-a9c6-406d-aefb-38f1e71e0fdb.png

This ticket was mentioned in PR #2455 on WordPress/wordpress-develop by mehedifoysal.


15 months ago
#18

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.

https://i0.wp.com/user-images.githubusercontent.com/52179233/159660790-c3a9a586-a9c6-406d-aefb-38f1e71e0fdb.png

mehedifoysal commented on PR #2455:


15 months 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.


15 months ago

#21 @ryokuhi
15 months 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.


14 months ago

#23 @mehedi890
14 months 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.


14 months ago

#25 @ryokuhi
14 months 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.

@sabernhardt
14 months ago

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

#26 @sabernhardt
14 months 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.

#27 @sabernhardt
14 months ago

  • Milestone changed from 6.0 to 6.1

This ticket was mentioned in Slack in #accessibility by ryokuhi. View the logs.


11 months ago

This ticket was mentioned in Slack in #accessibility by ryokuhi. View the logs.


10 months ago

This ticket was mentioned in Slack in #accessibility by chaion07. View the logs.


10 months ago

#31 follow-up: @sabernhardt
10 months 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.


9 months ago

This ticket was mentioned in Slack in #accessibility by sabernhardt. View the logs.


9 months ago

This ticket was mentioned in Slack in #accessibility by joedolson. View the logs.


9 months ago

#35 @ironprogrammer
9 months 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

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
https://cldup.com/Fq6yRwZ9et.png https://cldup.com/K8vjdYjZBu.png

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
https://cldup.com/w3ietWcpL7.png https://cldup.com/PhVZu4cuIE.png

#36 in reply to: ↑ 31 @ironprogrammer
9 months 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!

@sabernhardt
9 months ago

sub-menu expanded in Firefox at 788 pixels wide

#37 @sabernhardt
9 months 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

  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.

#38 @sabernhardt
9 months ago

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

#39 @sabernhardt
9 months 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', '' );
}

@sabernhardt
8 months ago

checks whether toolbar mobile menu toggle is showing or not

#40 @sabernhardt
8 months 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 ) ).)
Last edited 8 months ago by sabernhardt (previous) (diff)

This ticket was mentioned in Slack in #core by audrasjb. View the logs.


8 months ago

This ticket was mentioned in Slack in #core-test by sabernhardt. View the logs.


8 months ago

#43 @ironprogrammer
8 months 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 @costdev
8 months 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.
Last edited 8 months ago by costdev (previous) (diff)

This ticket was mentioned in Slack in #core-test by ironprogrammer. View the logs.


8 months ago

This ticket was mentioned in Slack in #accessibility by sabernhardt. View the logs.


8 months ago

#47 @ugyensupport
8 months 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.


8 months ago

This ticket was mentioned in Slack in #accessibility by abhanonstopnews. View the logs.


8 months ago

#50 @audrasjb
8 months 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.

@audrasjb
8 months ago

after patch: works fine

#51 @audrasjb
8 months ago

  • Keywords commit added

#52 @audrasjb
8 months ago

  • Resolution set to fixed
  • Status changed from accepted to closed

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.

This ticket was mentioned in Slack in #core by abhanonstopnews. View the logs.


8 months ago

Note: See TracTickets for help on using tickets.