Block API: Allow block transforms to handle iframes for non-admin users.

[pento]

Description

Fixes #18389.

In the event that a block has a raw transform which turns an iframe into a block, it isn't able to do so for non-admin users, since the iframe is stripped from the content before htmlToBlocks() is run in pasteHandler().

This PR allows htmlToBlocks() to run before stripping any iframes that weren't handled by block transforms.

How has this been tested?

Testing in conjunction with #19084 and Automattic/jetpack#13999, Google Calendar iframes are transformed into Google Calendar blocks.

Alternatively, this can be tested with the routine described in #18389.

Checklist:

• My code is tested.
• My code follows the WordPress code style.
• My code follows the accessibility standards.
• My code has proper inline documentation.
• I've included developer documentation if appropriate.
• I've updated all React Native files affected by any refactorings/renamings in this PR.

[ellatrix]

Could some sort of test be added?

[pento]

Added a new test, stripped down the number of filters that are re-run over the pasted content.

[ellatrix]

I see that it's been done previously, but why are we adding this block type for every test? Shouldn't we isolate it to the test?

[ellatrix]

Is this pathway tested? The tests seem to pass even with the code removed.

[ellatrix]

@pento This PR makes me wonder if removing the iframe on paste is actually the right behaviour. Wouldn't it be simpler to let the iframe be pasted, regardless if you can post them or not? The paste handler should ideally not be dependent on any user capabilities. If a user cannot use iframes in a post, they should be removed on publish or on rendering the post, which already happens? After all, they could still paste the iframes in HTML mode. How about just removing the filter?

[pento]

Thanks for the review, @ellatrix.

This PR makes me wonder if removing the iframe on paste is actually the right behaviour. Wouldn't it be simpler to let the iframe be pasted, regardless if you can post them or not?

I have no strong feelings either way: I understand why it exists, as if you paste an iframe as an Author, there's no indication that it'll be removed until you either preview/publish, or reload the block editor. But, you're right that the code would be simpler without this check.

After all, they could still paste the iframes in HTML mode.

I'm not so concerned about this, since HTML mode has always been a "warranty is neither expressed nor implied" scenario.

[ellatrix]

I've been thinking a bit more about this...

• We're talking about changing the behaviour on (external) paste, which is probably a scenario where we should be careful with iframes.
• The current way of handling iframe is not super useful. It's cool that it works when you have unfiltered HTML capabilities, in which case it will be put in the "advanced" HTML block. In other words, pasting iframes only works for some people, it wouldn't be a proper block, and pasting iframes generally from outside Gutenberg is a bit questionable.

I therefore propose to always convert iframes to a plain URL from its source attribute.

• Blocks can add transforms matching this URL, just like the embed block does.
• Paste no longer has to depend on user capabilities.

I'll follow up with a new PR.

[ellatrix]

Fixed by #20983.