Fix shift+tab from post title #69520
Draft
+51
−33
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
stokesman
added
[Type] Bug
|
Size Change: -24 B (0%) Total Size: 1.84 MB
ℹ️ View Unchanged
|
6 tasks
|
The e2e test I added is failing in Firefox yet testing manually in Firefox works as expected. In the e2e focus is ending up on the UPDATE: I can reproduce testing manually. It only happens when the canvas is iframed and the post is new. The "Open publish panel" button is the last tab stop in the page. It’s like Firefox is moving focus as if the active element were the |
I've discovered a few clues regarding this. It seems that the tab focus doesn't work well if the block inserter button is displayed in Firefox: 157e2275d4bc809adcac96740b3296a3.mp4But I don't know why this problem only occurs in Firefox 🤷 |
- Avoid error if focus capture elements are not present by returning early. - Support navigation from generic elements within the container, such as the post title, by removing early return for no block selection.
stokesman
force-pushed
the
fix/tab-nav-hook
branch
from
4027a79 to
c73b0c9
Compare
stokesman
changed the title
|
I figured out the issue in Firefox. It stems from two event listeners moving focus—first on Like Aki noted, this corresponds with when the default block appender button is visible, though merely because the second focus move is conditioned to happen only if no blocks are present. The solution I’ve tried in c73b0c9 was to remove the second movement. From my testing the conditions where it actually happened are very rare and I haven’t yet seen what good it actually does. On the contrary it causes a focus loss in some. I have tried to figure it out by looking into the history, it’s from ac07149 which certainly doesn’t make it obvious. It’s clearly intended for a undo related concern so that pretty much means it should not be happening from a tab navigation. An alternative to removing it would be refining the conditions so won’t interfere with tab navigation. Now the e2e I added is passing but many other tests aren’t. They seem unrelated failures and they’re passing locally. I noticed some of the recent PRs are experiencing the same. I’ll keep this drafted anyway until that’s sorted out. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What?
Closes #69486
Enables shift+tab from the post title (in "post-only" mode) to navigate to the preceding tab stop as expected.
Why?
The inability to navigate to the previous tab stop from the post title breaks keyboard use and is a regression since WP 6.7.
How?
Testing Instructions
E2E test
git switch -)Testing Instructions for Keyboard
General testing of tab navigation