Sidebar: Avoid focus loss on active tab change#10917
Conversation
|
Thanks @aduth, this is very helpful. I will try to find some time today to start working on a fix. |
|
I consolidate both sidebars into one component with 678819 and it solves the issue. It reuses the same Fill with the updated implementation so it is able to re-render (instead of unmount and mount) even when the active tab changes. |
|
@vindl - just letting you know that this changes a bit the logic inside the |
|
@afercia this should be ready to verify 👍 E2e tests fail but this is unrelated. I bet focus loss check should be enabled only for tests which use keyboard navigation, not to all of them. |
|
@gziolo thanks. I'm not seeing the sidebar at all. When I click the Settings button, I see the |
56ab3c8 to
d5ff172
Compare
There was a problem hiding this comment.
@aduth - it seems to fail too many test suites. I moved it to utils and applied only for the sidebar. Let's open a follow-up and this assertion where it fits.
There was a problem hiding this comment.
I also reverted changes applied to setup-test-framework.js with 46a078f.
There is this issue that afterEach removes all page listener but afterAll needs them, too.
|
@afercia it was my mistake, it should be fixed with d5ff172#diff-b006c664acf96e390063ef30c215b267R60 - I did a typo when refactoring code at the end of the day ... |
|
@gziolo LGTM 👍 thanks! |
0004cb7 to
dd7e54b
Compare
tofumatt
left a comment
There was a problem hiding this comment.
Ran the test steps locally and it worked a treat. The code makes sense and the tests passed, so ![]()
| > | ||
| <SettingsHeader sidebarName={ SIDEBAR_NAME } /> | ||
| <Panel> | ||
| <PanelBody className="edit-post-block-sidebar__panel"> |
There was a problem hiding this comment.
There's still an occurrence of this now-removed class name in tests:
Tests are currently running, but if they're passing that would be equally concerning.
|
Update: I ran the tests on master by mistake but I verified the fix manually on the branch, sorry. Running them on the right branch now 😓 |
There was a problem hiding this comment.
Locally I'm getting a failure on:
> ● splitting and merging blocks › should remove at most one paragraph in forward direction
Sorry, I thought I clicked "submit review" hours ago but I guess not, I'm just the worst on this PR 😓
From the looks the snapshot is wrong so something is off here and needs fixing.
|
|
||
| // Tweak the columns count. | ||
| await page.focus( '.edit-post-block-sidebar__panel .components-range-control__number[aria-label="Columns"]' ); | ||
| await page.focus( '.edit-post-settings-sidebar__panel-block .components-range-control__number[aria-label="Columns"]' ); |
removePageEvents now called in afterEach
4d5beff to
f779391
Compare
@tofumatt - it works properly for me locally and on Travis |
|
Travis is finally happy! 🎉 |
|
In spirit I give my approval, though despite @gziolo doing the bulk of the work, I can't review a pull request I'd opened 😄 |
youknowriad
left a comment
There was a problem hiding this comment.
despite @aduth doing the bulk of review work, he can't review the pull request he opened 😄so I'm approving :P
Test failure resolved #10917 (comment)

Partially addresses: #8079
This pull request seeks to resolve an issue of focus loss when changing active sidebar tabs for the editor settings sidebar ("Document", "Block").
Currently, this pull request includes all but the fix itself. Notably, included is an end-to-end test case covering the expected behavior, and a global test event handler protecting against unexpected focus loss.Update: It has been implemented with 72569ab.
Implementation notes:
Focus loss occurs because each specific sidebar renders the entirety of the
.edit-post-wrapperelement. For editor settings, this also includes the tab header as well.The bug occurs because React is unable to reconcile the two element trees, and is therefore forced to unmount and remount an entirely new sidebar wrapper.
An initial attempt here was to invert rendering, having each specific sidebar populating only the
Fillof the sidebar component, whereas theSlotwould be responsible for rendering the.edit-post-wrapperwrapper element. This has the added advantage of fixing an issue with the application ofwithFocusReturn, as currently this is broken since it's applied to theFill(non-DOM) element. An issue with this approach is in respecting thearia-labelapplication provided by each specific sidebar.Testing instructions:
Verify that no focus loss occurs when changing tabs in the sidebar.
Ensure end-to-end tests pass: