Bug with dom.event.clipboardevents.enabled setting to FALSE when you paste on Facebook
Categories
(Core :: DOM: Events, defect, P3)
Tracking
()
| Tracking | Status | |
|---|---|---|
| platform-rel | --- | - |
People
(Reporter: infoplus007, Unassigned)
References
Details
(Whiteboard: [platform-rel-Facebook])
Attachments
(1 file)
|
3.04 MB,
video/quicktime
|
Details |
|
Reporter | |
Comment 2•8 years ago
|
||
|
||
Updated•8 years ago
|
|
|
||
Updated•8 years ago
|
|
||
Comment 3•8 years ago
|
||
|
|
||
Comment 4•5 years ago
|
||
We are considering to close this as invalid.
Masayuki had a good comment -
" looks like it's invalid because Facebook has paste event listener at the <html> element. Even if beforeinput event will be enabled, its dataTransfer is not accessible when the pref is disabled for the security (i.e., web apps cannot handle pasting by themselves anyway). It'd be nicer if somebody investigates how Facebook to prevent normal pasting of browser without paste event before closing the bug."
CC Mike so that when his team has bandwidth, maybe they can help investigate a bit a confirm it's safe to close.
|
||
Updated•5 years ago
|
|
||
Comment 5•5 years ago
|
||
Note: The same problem exists with twitter.com when we want to paste in a new tweet form.
With the old twitter.com, there was no problem but since 1th June 2020, the old twitter has been removed.
Thanks in advance.
|
|
||
Comment 6•5 years ago
|
||
OK, so this still reproduces even with the new FB design.
It seems to break in 2 distinct ways, when commenting or creating a new post.
Test 1 (with "dom.event.clipboardevents.enabled" set to false, and making sure to paste plain text):
- Open FB, and click inside "What's on your mind, <Person>?" to make a new post.
- Paste the text from
data:text/html, <textarea>one. two. three</textarea>into the FB editor.
Expected: paste happens
Actual: the editor disappears and you get the following error in console:
Node.removeChild: The node to be removed is not a child of this node [Caught in: ErrorBoundary base]. But then FB swallows the rest of the error.
There's also a UI message "Something isn't working. This may be because of a technical error we're working to fix."
Test 2 (with "dom.event.clipboardevents.enabled" set to false, and making sure to paste plain text):
- Open FB, and click inside "What's on your mind, <Person>?" to make a new post.
- Paste plain text with a line break in it into the editor:
one. two. three.
text with a line-break.
Expected: nothing weird
Actual: here we see the duplicated text the original report describes.
- Now, type "hello".
Expected: nothing weird
Actual: hello appears backwards, in the middle of the repeated text content. deleting isn't possible. if you type more chars, it will dupe them one or two times, then the editor disappears with the same error as above.
If I repeat STR on https://draftjs.org/, I end up with a white page and the same error:
DOMException: Node.removeChild: The node to be removed is not a child of this node
Maybe a good place to start is with a bug to FB in that repo.
|
|
||
Comment 7•5 years ago
|
||
|
|
||
Comment 8•5 years ago
|
||
I filed https://github.com/facebook/draft-js/issues/2557
Masayuki, have you seen a similar type of bug before with the backwards text (see the screencast)? It's still possible this is DraftJS bug and not ours, we can try to dig in more if it's helpful.
|
|
||
Updated•5 years ago
|
(In reply to Mike Taylor [:miketaylr] from comment #8)
Masayuki, have you seen a similar type of bug before with the backwards text (see the screencast)? It's still possible this is DraftJS bug and not ours, we can try to dig in more if it's helpful.
No, I don't see it. Our editor works with selection (caret if collapsed) sensitively. So, I have no idea that our editor inserting text into different position from the caret position. I guess that the web apps handles input event and replaces what you inserted with what they want. E.g., when I paste too big HTML fragment (e.g., all of a long bug page), I see formatted text. So, the insertion point issue must be they handle something wrong.
Although Facebook will support Firefox with dom.event.clipboardevents.enabled to false in this week if nothing becomes a problem. Anyway, this is an INVA bug from point of view of browser side and dup of bug 1104117.
Description
•