1664114 - Can't copy text from disabled textarea or text input if webpage has a contenteditable element

Status: RESOLVED FIXED

(Core :: DOM: Editor, defect)

Description

[John Nguyen]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:80.0) Gecko/20100101 Firefox/80.0

Steps to reproduce:

Minimal reproduction page: https://codesandbox.io/s/condescending-hermann-8zttt?file=/index.html:375-390

1. Open a webpage contains a disabled input element and another element with contenteditable attribute set to true.
2. Highlight the disabled text input value
3. Try to copy the highlighted text value, either via Ctrl-C or context menu

Actual results:

The selected text input value is not copied into clipboard

Expected results:

The selected text input value should be put into clipboard

Comment 1

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

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Comment 2

[John Nguyen]

This is similar to original bug report https://bugzilla.mozilla.org/show_bug.cgi?id=253870 , which was marked as FIXED sometime ago.

I can still replicate this bug in a fresh install of Firefox Nightly:
Name Firefox
Version 82.0a1
Build ID 20200909213959
User Agent Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:82.0) Gecko/20100101 Firefox/82.0
OS Darwin 19.6.0 Darwin Kernel Version 19.6.0: Thu Jun 18 20:49:00 PDT 2020; root:xnu-6153.141.1~1/RELEASE_X86_64
Application Binary /Applications/Firefox Nightly.app/Contents/MacOS/firefox

Comment 3

[Emilio Cobos Álvarez (:emilio)]

Huh, odd that selection works but copy/paste doesn't. Looking.

Comment 4

[Emilio Cobos Álvarez (:emilio)]

Attachment: Testcase from reporter.

Comment 5

[Emilio Cobos Álvarez (:emilio)]

So I dug a bit into this today, and I have a couple potential fixes, but nothing really exciting...

So the issue is that when we have an HTMLEditor, we add a command controller here to deal with all the editing commands, including copy.

That goes through CopyCommand and such which only considers the editor's selection, not the last focused selection here.

So, issues:

• GetControllerForCommand returns the HTMLEditor copy command even when not editing or not allowed to copy. That's a bit unfortunate.
• Then that doesn't look at the last focused selection.
• Then we don't try to execute commands from other controllers.

I'm going to submit the fix I came up with, though I tried other things that seemed better, but ended up not quite being ok like:

• https://treeherder.mozilla.org/#/jobs?repo=try&revision=f6c2d5dfbbf738f114b01e3b91dcc05f87b8fc1e

Comment 6

[Emilio Cobos Álvarez (:emilio)]

Attachment: Bug 1664114 - Factor out a condition to unconditionally enable clipboard events in some documents. r=masayuki

This patch shouldn't introduce any behavior change.

Comment 7

[Emilio Cobos Álvarez (:emilio)]

Attachment: Bug 1664114 - Try to find a more usable selection for copy-paste if copying from an HTMLEditor. r=masayuki

See the bug for the complications that made me write this slightly hacky
fix... Other solutions definitely welcome.

Add a test, adjusted so it would fail without the change.

Depends on D89834

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/5dd737d76ead
Try to find a more usable selection for copy-paste if copying from an HTMLEditor. r=masayuki

Comment 9

[Emilio Cobos Álvarez (:emilio)]

I'll move the cleanup to another bug.

Comment 10

[Phabricator Automation]

Comment on attachment 9175057 [details]
Bug 1664114 - Factor out a condition to unconditionally enable clipboard events in some documents. r=masayuki

Revision D89834 was moved to bug 1664411. Setting attachment 9175057 [details] to obsolete.

Comment 11

[Bogdan Tara[:bogdan_tara | bogdant]]

https://hg.mozilla.org/mozilla-central/rev/5dd737d76ead