-
Notifications
You must be signed in to change notification settings - Fork 4.7k
Description
In #36356 we found a bug whereby internally pasted links were prefixed with a <meta charset> tag. When trying to add an integration test to cover this I discovered we're missing test coverage for any internally pasted content that comes from a rich text instance.
More info below:
I was looking at adding an integration test to cover this. Initially it seemed like we already have one but upon closer testing it doesn't assert on the same problem.
According to the usePasteHandler code, if the content is identified as being "internal"...
| const isInternal = clipboardData.getData( 'rich-text' ) === 'true'; |
...then all the filters in pasteHandler are skipped.
gutenberg/packages/block-editor/src/components/rich-text/use-paste-handler.js
Lines 128 to 131 in 7a41d02
| // If the data comes from a rich text instance, we can directly use it | |
| // without filtering the data. The filters are only meant for externally | |
| // pasted content and remove inline styles. | |
| if ( isInternal ) { |
These filters are those within pasteHandler - one of which strips meta (such as is fixed by this PR).
Therefore the integration test which exclusively uses pasteHandler and includes a test for <meta charset> will pass, but this bug where meta is added to internal pasted content will continue to manifest itself in the Editor.
It looks like we can't pass inline pasted content through pasteHandler as it will strip things that are considered safe within an inline context. However, perhaps we need to modify pasteHandler with an inline-rich mode to allow us to apply selective filters to rich inline content.
If we don't do something it's going to be very difficult to assert on the handling of pasting rich inline content. For example, I tired adding an e2e tests to cover the <meta charset scenario but the "bug" will not manifest in Puppeteer.
Do you have any thoughts on the best way forward here?
Originally posted by @getdave in #36356 (comment)