Opened 15 months ago
Last modified 13 days ago
#55342 new defect (bug)
If the contextual help panel is open and then I scroll, I have to click on help twice to close the panel
Reported by: |
|
Owned by: | |
---|---|---|---|
Milestone: | 6.3 | Priority: | normal |
Severity: | minor | Version: | 5.9.1 |
Component: | Help/About | Keywords: | has-patch needs-testing |
Focuses: | ui, javascript | Cc: |
Description
Steps to reproduce:
- click "Help" to open a contextual help panel
- scroll
- click "Help" to close the panel; note that it does not close
- click "Help" again; note that it does close this time
This is annoying for the user--can this be solved so that it only takes one click to close the contextual help after scrolling?
In our plugin, we are using enough contextual help on one page that you have to scroll to reach the "Help" button (#contextual-help-link") to close it again.
Further notes: I have a live expression for document.activeElement in the console. On the first attempt to close the section, the document.activeElement shows:
button#contextual-help-link.button.show-settings.screen-meta-active
on the second, click it shows:
button#contextual-help-link.button.show-settings
More info:
happens in several tested themes (2022, 2021, 2020)
happens when all plugins are deactivated
Chrome/Edge/Firefox, Windows 10, Ubuntu 20.04
Change History (5)
#1
@
11 months ago
- Focuses javascript added
- Keywords needs-patch added
- Milestone changed from Awaiting Review to Future Release
This ticket was mentioned in PR #4272 on WordPress/wordpress-develop by @studionashvegas.
2 months ago
#2
- Keywords has-patch added; needs-patch removed
This request fixes a bug in the WordPress Admin screen. Currently, opening the contextual help menu, scrolling, and trying to close the Help menu causes the user to have to click twice to scroll thanks to the behavior of scrollIntoView()
. This request changes that function to use scrollIntoViewIfNeeded()
which allows the user to successfully close the contextual menu with one click.
#3
@
2 months ago
I've submitted the PR above to fix this issue - it's been a while since I've contributed, so if I've forgotten a step in the process please let me know; otherwise, I've verified this works on trunk and does indeed solve the issue.
Hi and thanks for the report!
This seems related to the
scrollIntoView
WebKit fix added in r22249.