#53587 closed defect (bug) (fixed)
Mobile: Admin menu: Click on content should hide the menu
Reported by: | kaneva | Owned by: | joedolson |
---|---|---|---|
Milestone: | 6.2 | Priority: | normal |
Severity: | normal | Version: | |
Component: | Administration | Keywords: | has-testing-info has-patch commit |
Focuses: | ui, accessibility, javascript, administration | Cc: |
Description
Steps to reproduce:
- Use a mobile device
- Go to the admin via the browser
- Expand the admin menu
- Click on the content on the right side
- Observe admin menu does not hide
I expect the menu to hide when I click on the content. Additionally, I expect the content on the right half to be non interactive.
Attachments (5)
Change History (65)
#1
follow-up:
↓ 5
@
3 years ago
- Focuses ui accessibility javascript added
Hi @kaneva and thanks for the report!
We should also consider closing the admin menu on focus state within the content area (when using the Tab key with desktop browser zoom of 200% or more).
This ticket was mentioned in Slack in #accessibility by joedolson. View the logs.
3 years ago
This ticket was mentioned in PR #1584 on WordPress/wordpress-develop by costdev.
3 years ago
#4
- Keywords has-patch added; needs-patch removed
Added a focusout
event listener to #wp-admin-bar-menu-toggle
and #adminmenumain
.
Provided that $wpwrap.hasClass( 'wp-responsive-open' )
, and neither of the above parents or their children contain the newly focused element, the sidebar will close.
N.B. While the sidebar is open, non-sidebar content doesn't respond to the first input attempt, negating any impact of accidental click or touch events.
Trac ticket: https://core.trac.wordpress.org/ticket/53587
#5
in reply to:
↑ 1
@
3 years ago
Replying to sabernhardt:
Hi @kaneva and thanks for the report!
We should also consider closing the admin menu on focus state within the content area (when using the Tab key with desktop browser zoom of 200% or more).
The submitted patch also closes the menu in this circumstance.
#6
@
3 years ago
Pinging for advice from @joedolson, are you happy to progress this ticket or is there someone else you'd recommend I reach out to?
This ticket was mentioned in Slack in #core by audrasjb. View the logs.
3 years ago
#11
@
3 years ago
Reviewed during today's bug scrub.
The patch still applies cleanly against trunk.
In my testing it fixes the underlined issue. Probably a good commit candidate.
#12
@
3 years ago
- Keywords commit added
- Milestone 5.9 deleted
- Resolution set to invalid
- Status changed from accepted to closed
hellofromtonya commented on PR #1584:
3 years ago
#16
Committed via https://core.trac.wordpress.org/changeset/51946.
#17
@
3 years ago
- Keywords commit removed
- Resolution fixed deleted
- Status changed from closed to reopened
#18
@
3 years ago
Spoke with @joedolson on slack who confirmed okay to revert [51946] and move resolution to 6.0.
I'll take care of the revert commit shortly.
#19
@
3 years ago
- Owner changed from joedolson to hellofromTonya
- Status changed from reopened to reviewing
Self-assigning for the revert to trunk
and 5.9
branch.
#21
@
3 years ago
- Keywords dev-feedback commit added; has-patch removed
Marking for 2nd committer's review to revert [51946] in the 5.9 branch.
#22
@
3 years ago
- Keywords dev-reviewed fixed-major added; dev-feedback removed
This changeset can be reverted in branch 5.9 as it currently fixes the underlined issue on trunk
.
#25
@
3 years ago
- Keywords commit dev-reviewed fixed-major removed
- Milestone changed from 5.9 to 6.0
- Owner changed from hellofromTonya to joedolson
[51946] is now reverted on both trunk
and 5.9
branches. Resetting keywords, moving to 6.0, and resetting ownership.
This ticket was mentioned in Slack in #core by audrasjb. View the logs.
3 years ago
joedolson commented on PR #1584:
3 years ago
#27
Reopening, since this was reverted prior to release.
This ticket was mentioned in Slack in #core by chaion07. View the logs.
3 years ago
This ticket was mentioned in Slack in #accessibility by ryokuhi. View the logs.
3 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 ryokuhi. View the logs.
2 years ago
#33
@
2 years ago
- Keywords needs-refresh needs-testing added
We reviewed the ticket today during the Accessibility Team's weekly bug scrub.
The patch in this ticket was committed and then reverted because of the hard-to-reproduce bug reported in #54837.
I'm reporting here the testing instructions from the above ticket: if, after applying the patch, someone is able to reproduce the bug and give extra information, please add a comment below.
- Use a mobile device (tested with iPhone)
- Login to admin via browser (tested with Safari and Chrome)
- Expand the admin menu
- Click on one of the main items (Posts, Users, etc)
- Admin menu is hidden
- Open menu again
- Item clicked has been expanded showing subitems.
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
This ticket was mentioned in Slack in #core by audrasjb. View the logs.
2 years ago
#38
@
2 years ago
As per today's bug scrub: the above issue still need to be reproduced.
It looks like it was produced using iOS with iPhone 11 or 12.
This ticket was mentioned in Slack in #accessibility by sabernhardt. View the logs.
2 years ago
#40
@
2 years ago
- Keywords needs-testing removed
Alright, I tested the pull request on iOS (iPhone 11) and the menu closes when I click in the content, but I found another bug and I not sure if it is related to the changeset or not: when you try to open a menu which contains a submenu, the admin menu closes itself, and you have to reopen it to click on the sub item.
Maybe it's related to this change, maybe not, but worth fixing this behavior :)
#41
@
2 years ago
@audrasjb That is the issue reported against this change: see #54837, which was the reason this was reverted. So that's a confirmation that the issue still exists and still needs to be addressed. Somebody with an iPhone 11 will probably have to work on this, since I couldn't reproduce using emulation.
This ticket was mentioned in Slack in #accessibility by joedolson. View the logs.
2 years ago
This ticket was mentioned in Slack in #accessibility by sabernhardt. View the logs.
2 years ago
#45
@
2 years ago
The patch relies on the wp-responsive-open
class, but that is not always accurate. At least when resizing the window—or switching a phone's orientation between vertical and horizontal—the script does not update the wp-responsive-open
class (or the aria-expanded
attribute).
This may or may not relate to the reported iPhone issue.
This ticket was mentioned in Slack in #accessibility by ryokuhi. View the logs.
21 months ago
This ticket was mentioned in Slack in #accessibility by ryokuhi. View the logs.
21 months ago
This ticket was mentioned in Slack in #accessibility by ryokuhi. View the logs.
20 months ago
#49
@
20 months ago
I made a few tests today using an iPhone with iOS 15: I was able to reproduce both the original issue (when tapping outside of the admin menu, the menu doesn't close), and the issue that caused the revert (after the patch is applied, if you tap on one of the main menu items, the admin menu closes).
In case someone is able to fix the issue and needs testing, I should be able to provide it, possibily in time for 6.2 Beta 1 release.
This ticket was mentioned in Slack in #accessibility by ryokuhi. View the logs.
20 months ago
#51
@
20 months ago
- Keywords needs-testing has-patch added; needs-refresh removed
All right; using the information from @ryokuhi and managing to set up a test case on iOS, I've got a fix for the issue.
The problem was that on iOS, the submenu trigger was causing a loss of focus; by monitoring document.activeElement, I could see that the activeElement shifted to the body
when submenus were toggled. This caused focusIsInToggle and focusIsInSidebar to return true.
Resolved this by triggering focus on the submenu trigger after toggling.
In addition, I added an escape on ! document.hasFocus()
so that the menu wouldn't close if the user switches focus to another tab, window, or application.
#52
@
20 months ago
The jsvalidate:build
stage complained about a comma in the console.log
line, though you may have intended to remove the full line anyway.
I was nervous about using the wp-responsive-open
class, but I did not notice any problems when resizing the window around the breakpoint in Firefox.
#53
@
20 months ago
Thanks for noting that, @sabernhardt.
It didn't seem to me that the wp-responsive-open
class dependency was significant; I couldn't find any reason for it to cause a problem.
I think we should commit this and move it forward. If there are additional issues, they should be spotted in beta.
This ticket was mentioned in PR #4067 on WordPress/wordpress-develop by @joedolson.
20 months ago
#54
Close admin nav menu when focus moves into the body.
Trac ticket: https://core.trac.wordpress.org/ticket/53587
#55
@
20 months ago
- Keywords commit added; needs-testing removed
I've tested in iOS and confirmed that prior to this change the menu closed when activating a menu item with children, and after the change the menu only closes when focus is moved to body.
Marking to commit based on prior approval, passing tests, and tests on iOS.
@joedolson commented on PR #1584:
20 months ago
#58
Closed with https://core.trac.wordpress.org/changeset/55326
The menu in question