Firefox 117 no copy event is generated when pressing CTRL+C with no selected text in a div element with contenteditable set to true
Categories
(Core :: DOM: Editor, defect)
Tracking
()
People
(Reporter: timur, Assigned: sefeng)
References
(Regression)
Details
(Keywords: regression, regressionwindow-wanted)
Attachments
(1 file)
1.39 MB,
video/x-matroska
|
Details |
Steps to reproduce:
Ctrl+c to copy in a text element with contenteditable='true'..
Actual results:
No copy/cut input event is emitted when CTRL+C/X is pressed, from FF 117.
Expected results:
Copy should work, as for a textArea element.
Comment 1•1 year ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::DOM: Editor' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.
Comment 2•1 year ago
|
||
Could you upload a screen recording demonstrating this failure? I've been unable to reproduce using either 117.0.1 or 119.0a1 under Fedora Linux.
Screencast of Copy by menu OK and by Ctrl+C NOK in Collabora Online.
Problem started wth TextInput: switch from <textarea> to contenteditable.
Updated•1 year ago
|
Comment 4•1 year ago
|
||
Repros with data:text/html,<div contenteditable=true oncopy='alert(1)'>Copy</div>
if there's no selected text.
Looks like that this start point is wrong. I think that it should start from Selection::GetFocusNode()
or the result of ComputeEditingHost(LimitInBodyElement::Yes)
if IsHTMLEditor()
is true
. I guess that this is regressed by bug 1817723 which touched GetDOMEventTarget()
.
Looks like that using startContainer
of first Selection
Range
is right start point.
https://searchfox.org/mozilla-central/rev/36a0e62e4484f707e1eb88a6f3968c9ed72d0795/dom/base/nsCopySupport.cpp#752,754-755,760-761,789-790
Comment 7•1 year ago
|
||
I don't think this is a recent regression, at least I couldn't find an old revision that didn't reproduce the issue.
Last good revision: b040fff76ed7ecee270c125c9c3229c5e9ee1ff0
First bad revision: f9f8e7cfe057c0d11fd0795b1b8da2400880840c
Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=b040fff76ed7ecee270c125c9c3229c5e9ee1ff0&tochange=f9f8e7cfe057c0d11fd0795b1b8da2400880840c
Comment 9•1 year ago
|
||
:sefeng, since you are the author of the regressor, bug 1817723, could you take a look?
For more information, please visit BugBot documentation.
Assignee | ||
Updated•1 year ago
|
Assignee | ||
Comment 10•1 year ago
|
||
At least bug 1817723 doesn't regress data:text/html,<div contenteditable=true oncopy='alert(1)'>Copy</div>
. Before bug 1817723, the starting point is document which is still wrong because the event listener is registered on the div
element. I'll submit a patch in a different bug to fix data:text/html,<div contenteditable=true oncopy='alert(1)'>Copy</div>
by using Masayuki's suggestion.
Timur, I don't have access to Collabora Online
, do you think you can provide a reduced test case which the regression range is what you've provided in comment 8?
Assignee | ||
Comment 11•1 year ago
|
||
(I filed Bug 1857303 for data:text/html,<div contenteditable=true oncopy='alert(1)'>Copy</div>
. In fact I am not going to write a patch, instead I marked it as a good-first-bug
)
Reporter | ||
Comment 12•1 year ago
|
||
First, I applogize I did not verify prevoius bisect result, I bibisected again and it is different, I verified this one. It is still v117 but somehow there are many commits in this pushlog.
Last good revision: e4d87ff75575880ea0c0fa09b316e360e4d9492f
First bad revision: 511a6a347d490d95f83e47414d604a17e143c218
Pushlog:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=e4d87ff75575880ea0c0fa09b316e360e4d9492f&tochange=511a6a347d490d95f83e47414d604a17e143c218
Collabora Online has Demo or I can provide a link to some document, but that will not be useful for current versions, as we reverted switch from <textarea> to content editable <div>, when this issue emerged.
So really I can test only by building between our commit d7e302c94a35ef61595270727dec6c6013c2a63a and 97aec607666e3e3170a2fea5154a50db081876a3.
Or we all can test by running Collabora Online docker 23.05.1 up to 23.05.3, together with Nextcloud docker - it takes some setting, though.
Reporter | ||
Comment 13•1 year ago
|
||
The example provided on bugzilla <div contenteditable=true oncopy='alert(1)'>Copy</div> fails to work in 115, 117, 118.
Collabora Online works on 115 and fails on 117 and 118. The difference is that in online the oncopy handler is defined for document and not for the div element.
In fact the following small html sample behaves exactly as Collabora Online:
<html>
<body>
<div contenteditable=true>Copy</div>
</body>
<script>
document.oncopy = function() { alert(1); };
</script>
</html>
On Windows the problem doesn't seem occur for any Firefox version.
Assignee | ||
Comment 15•1 year ago
|
||
Hi, can you try the latest Nightly and see if this has been fixed?
Reporter | ||
Comment 16•1 year ago
|
||
Hi. Seems OK to me, thanks, but please let us some time, I will write here and not forget.
Reporter | ||
Comment 17•1 year ago
|
||
OK, this is Fixed - please note if it will be backported. Thanks.
Updated•1 year ago
|
Description
•