1853650 - Firefox 117 no copy event is generated when pressing CTRL+C with no selected text in a div element with contenteditable set to true

Status: RESOLVED DUPLICATE of bug 1857303

(Core :: DOM: Editor, defect)

Description

[Timur]

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

[BugBot [:suhaib / :marco/ :calixte]]

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

[Adam Vandolder [:avandolder]]

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.

Comment 3

[Timur]

Attachment: 2023-09-19 11-29-01.mkv

Screencast of Copy by menu OK and by Ctrl+C NOK in Collabora Online.
Problem started wth TextInput: switch from <textarea> to contenteditable.

Comment 4

[Emilio Cobos Álvarez (:emilio)]

Repros with data:text/html,<div contenteditable=true oncopy='alert(1)'>Copy</div> if there's no selected text.

Comment 5

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(away 4/27 - 5/6)]

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().

Comment 6

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(away 4/27 - 5/6)]

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

[Emilio Cobos Álvarez (:emilio)]

I don't think this is a recent regression, at least I couldn't find an old revision that didn't reproduce the issue.

Comment 8

[Timur]

Last good revision: b040fff76ed7ecee270c125c9c3229c5e9ee1ff0
First bad revision: f9f8e7cfe057c0d11fd0795b1b8da2400880840c
Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=b040fff76ed7ecee270c125c9c3229c5e9ee1ff0&tochange=f9f8e7cfe057c0d11fd0795b1b8da2400880840c

Comment 9

[BugBot [:suhaib / :marco/ :calixte]]

:sefeng, since you are the author of the regressor, bug 1817723, could you take a look?

For more information, please visit BugBot documentation.

Comment 10

[Sean Feng [:sefeng]]

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?

Comment 11

[Sean Feng [:sefeng]]

(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)

Comment 12

[Timur]

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.

Comment 13

[Timur]

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.

Comment 14

[Sean Feng [:sefeng]]

Thanks, Bug 1857303 fixes too!

Comment 15

[Sean Feng [:sefeng]]

Hi, can you try the latest Nightly and see if this has been fixed?

Comment 16

[Timur]

Hi. Seems OK to me, thanks, but please let us some time, I will write here and not forget.

Comment 17

[Timur]

OK, this is Fixed - please note if it will be backported. Thanks.