-
Notifications
You must be signed in to change notification settings - Fork 4.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Block Editor: Consistently render IgnoreNestedEvents for block appender #19135
Changes from 2 commits
ac00564
cd494a7
9091e97
3b2132f
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -10,6 +10,8 @@ import { | |
insertBlock, | ||
} from '@wordpress/e2e-test-utils'; | ||
|
||
const getActiveBlockName = async () => page.evaluate( () => wp.data.select( 'core/block-editor' ).getSelectedBlock().name ); | ||
|
||
describe( 'Writing Flow', () => { | ||
beforeEach( async () => { | ||
await createNewPost(); | ||
|
@@ -20,7 +22,11 @@ describe( 'Writing Flow', () => { | |
// not be necessary for interactions, and exist as a stop-gap solution | ||
// where rendering delays in slower CPU can cause intermittent failure. | ||
|
||
let activeElementText; | ||
// Assertions are made both against the active DOM element and the | ||
// editor state, in order to protect against potential disparities. | ||
// | ||
// See: https://github.com/WordPress/gutenberg/issues/18928 | ||
let activeElementText, activeBlockName; | ||
|
||
// Add demo content | ||
await clickBlockAppender(); | ||
|
@@ -54,13 +60,19 @@ describe( 'Writing Flow', () => { | |
|
||
// Arrow up into nested context focuses last text input | ||
await page.keyboard.press( 'ArrowUp' ); | ||
activeBlockName = await getActiveBlockName(); | ||
expect( activeBlockName ).toBe( 'core/paragraph' ); | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I wonder if it wouldn't be best to verify instead that the block toolbar is visible at this point. From a user's perspective, that's what really matters, whereas the block being set as active in our data store is more of an implementation detail. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
That's a fair expectation we should want in these tests, I agree. The selected block name was more easily accessible and generally representative of what would be expected to be shown in the UI for the toolbar, but I'll see about making the assertion more targeted to the toolbar. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. In closer inspection, I don't think there's anything of the toolbar markup which can serve as a sufficient indication that the toolbar is showing for a paragraph block: I expect this is in-part due to the fact that core block icons are hard-coded, and not part of some keyed collection against which we can reference: https://github.com/WordPress/gutenberg/blob/master/packages/block-library/src/paragraph/icon.js The only options I could see here is either adding more markup to the toolbar for the sake of the tests, or comparing against this hard-coded SVG value. For the purposes of this test, I'm inclined to think we can be content with the current assertion against block editor state. If it proves to fail us in the future, it could be worth revisiting. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yup, we'll have to revisit if |
||
activeElementText = await page.evaluate( () => document.activeElement.textContent ); | ||
expect( activeElementText ).toBe( '2nd col' ); | ||
|
||
// Arrow up in inner blocks should navigate through (1) column wrapper, | ||
// (2) text fields. | ||
await page.keyboard.press( 'ArrowUp' ); | ||
activeBlockName = await getActiveBlockName(); | ||
expect( activeBlockName ).toBe( 'core/column' ); | ||
await page.keyboard.press( 'ArrowUp' ); | ||
activeBlockName = await getActiveBlockName(); | ||
expect( activeBlockName ).toBe( 'core/paragraph' ); | ||
activeElementText = await page.evaluate( () => document.activeElement.textContent ); | ||
expect( activeElementText ).toBe( '1st col' ); | ||
|
||
|
@@ -72,15 +84,21 @@ describe( 'Writing Flow', () => { | |
document.activeElement.getAttribute( 'data-type' ) | ||
) ); | ||
expect( activeElementBlockType ).toBe( 'core/column' ); | ||
activeBlockName = await getActiveBlockName(); | ||
expect( activeBlockName ).toBe( 'core/column' ); | ||
await page.keyboard.press( 'ArrowUp' ); | ||
activeElementBlockType = await page.evaluate( () => ( | ||
document.activeElement.getAttribute( 'data-type' ) | ||
) ); | ||
expect( activeElementBlockType ).toBe( 'core/columns' ); | ||
activeBlockName = await getActiveBlockName(); | ||
expect( activeBlockName ).toBe( 'core/columns' ); | ||
|
||
// Arrow up from focused (columns) block wrapper exits nested context | ||
// to prior text input. | ||
await page.keyboard.press( 'ArrowUp' ); | ||
activeBlockName = await getActiveBlockName(); | ||
expect( activeBlockName ).toBe( 'core/paragraph' ); | ||
activeElementText = await page.evaluate( () => document.activeElement.textContent ); | ||
expect( activeElementText ).toBe( 'First paragraph' ); | ||
|
||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I know this is a crucial part to fixing the bug 😅 , but this change has caused the original nav item appender bug to resurface in Firefox (though not in Chrome):
cc @draganescu
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, Firefox is the issue here and why the whole original attempt was so convoluted :D
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hm, reading this and #18379, I might expect this could be related a Firefox+macOS specific treatment of click events in buttons in which the clicks do not cause focus:
https://gist.github.com/cvrebert/68659d0333a578d75372
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/button#Clicking_and_focus
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There's a few related handlings of this in Gutenberg elsewhere:
gutenberg/packages/block-editor/src/components/block-list/insertion-point.js
Lines 54 to 60 in 74269e6
gutenberg/packages/block-editor/src/components/default-block-appender/index.js
Lines 38 to 49 in 74269e6
gutenberg/packages/components/src/higher-order/with-focus-outside/index.js
Lines 100 to 121 in 74269e6
Similarly, I'm thinking it could be enough to add a
tabIndex={ -1 }
to thediv
wrapper, which could allow the focus event to occur when the appender is clicked, while not adding an extra tab stop.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This seems to work in my testing. See 9091e97, which includes the test and an explanatory inline comment.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's working fine for me now 🎉