Fix e2e test: 'inserts a default block on bottom padding click'

[stokesman]

The test should include an assertion that the default block has focus as that is currently broken on trunk.

Right now it only asserts that the block is inserted:

gutenberg/test/e2e/specs/editor/various/inserting-blocks.spec.js

Lines 44 to 47 in 559edae

	expect( await editor.getBlocks() ).toMatchObject( [
	{ name: 'core/image' },
	{ name: 'core/paragraph' },
	] );

Old description from when this was first opened

So it looks like #64639 regressed the click below to add block (there should really have been some e2e tests).

There is one but apparently it doesn’t fail:

gutenberg/test/e2e/specs/editor/various/inserting-blocks.spec.js

Line 29 in 559edae

test( 'inserts a default block on bottom padding click', async ( {

Originally posted by @stokesman in #64992 (comment)

[t-hamano]

After investigating this issue, I found that this test hadn't failed before because it was being tested with TT1.

In classic themes such as TT1, the 8px padding is applied to the document:

gutenberg/packages/edit-post/src/classic.scss

Lines 14 to 15 in 6dae3c7

	html :where(.editor-styles-wrapper) {
	padding: 8px;

This satisfies the conditional statement below, allowing the block to be inserted:

gutenberg/packages/edit-post/src/components/layout/use-padding-appender.js

Lines 26 to 28 in 04cf579

	if ( ! paddingBottom ) {
	return;
	}

In block themes, however, this padding doesn't exist, so the above conditional statement is met and the early return prevents the block from being inserted.

Perhaps the conditional statement itself is unnecessary?

[stokesman]

Thanks for investigating. It looks like you’re right about why it wasn’t failing. So had it been ran against a block-based theme it would have failed with #64639.

The test does fail now if I break the hook. So I guess we can close this issue. I had not thought to quickly check that before making this and I just didn’t want to forget to follow up.

Perhaps the conditional statement itself is unnecessary?

As best I can tell the purpose of the early return in that case is to effectively disable the hook when editing in a context where the “typewriter” 40vh space isn’t being added. I think it would be better to truly disable the hook based on the same condition for adding the space. Then the hook doesn’t have try detecting the space and the condition can be removed.

I have a branch like that and am meaning to make it a PR to follow up.

[stokesman]

Reopened because focus of the default block is broken in trunk and this test was never asserting focus and it seems it should.