Pasting: Dismiss pasted image if file:// schema detected #42785
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Fixes #42783 This isn't the fix that I would like, and I am not sure that it should be merged. IMO, the underlying issue is that Google Chrome (and Chromium derivatives) decides to attach to the clipboard data the fallback snapshot provided by Microsoft Word. Other browsers ignore that data, only passing attachments of type `text/plain`, `text/html`, and sometimes `text/rtf`.
mcsf
added
[Type] Bug
|
Size Change: +37 B (0%) Total Size: 1.26 MB
ℹ️ View Unchanged
|
ellatrix
reviewed
Jul 29, 2022
| @@ -70,7 +70,16 @@ export function shouldDismissPastedFiles( files, html /*, plainText */ ) { | |||
| // other elements found, like <figure>, but we assume that the user's | |||
| // intention is to paste the actual image file. | |||
| const IMAGE_TAG = /<\s*img\b/gi; | |||
| return html.match( IMAGE_TAG )?.length !== 1; | |||
| if ( html.match( IMAGE_TAG )?.length !== 1 ) return true; | |||
There was a problem hiding this comment.
Why does this mean we should dismiss files? Should we check if the length is the same as the amount of files provided?
There was a problem hiding this comment.
Oh I see the files?.length === 1 check now.
There was a problem hiding this comment.
Yeah, the two if-statements combined mean that we can only dismiss files when there is a mismatch between the number of files and the number of IMG tags in the HTML. The first if-statement just reduces the surface area of this helper, making it more conservative (e.g. there haven't been reports of unexpected file pastes when there is more than one file, so might as well only check with files.length == 1).
ellatrix
approved these changes
Jul 29, 2022
Thanks for the vote of confidence! Yeah, let's keep a close eye on possible regressions, and if this comes back we should look into developing an integration suite. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What?
Fixes #42783
This isn't the fix that I would like, and I am not sure that it should be merged.
IMO, the underlying issue is that Google Chrome (and Chromium derivatives, including Microsoft Edge) decides to attach to the clipboard data the fallback snapshot provided by Microsoft Word. Other browsers ignore that data, only passing attachments of type
text/plain,text/html, and sometimestext/rtf.Why?
Quoting the bug report from the parent issue:
In short:
Gutenberg should ignore that attached snapshot.
How?
This PR extends the
shouldDismissPastedFilespredicate to detect cases where the image tag found in the pasted HTML payload has a source with schemafile://. For example,{ html: '<p>text</p><img src="file:///some/local/path">' }. Notes:clipboardData.fileswould be enough and we wouldn't have to guess based onclipboardData.getData( 'text/html' ). However, I haven't spotted any (meta)data in there that we could use.Testing Instructions
See parent issue.
Caveat
I'm confident that this PR fixes that particular edge case, but it makes assumptions that I don't like, potentially creating new classes of false positives.
There's always the possibility of filing an issue / asking around in the Chromium project, to determine whether we could consider this a browser bug.