New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 764051 link

Starred by 1 user

Issue metadata

Status: Duplicate
Merged: issue 761433
Owner:
Email to this user bounced
Closed: Sep 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Mac
Pri: 1
Type: Bug-Regression



Sign in to add a comment

document.execCommand('copy') doesn't add text to clipboard in certain situations in Canary

Reported by mpariz...@pdftron.com, Sep 11 2017

Issue description

UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3212.0 Safari/537.36

Steps to reproduce the problem:
1. Navigate to http://pdftron.com/webviewer/bugdemo/
2. Select some text on the document.
3. Press the "Copy" button that appears after the text is selected.

What is the expected behavior?
The selected text should be added to the OS clipboard.

What went wrong?
The selected text is not added to the clipboard. If you try this in Chrome 60 it works without any issues.

The project has a hidden textarea that we set the value of based on the selected document text. Then we temporarily show the textarea and call document.execCommand('copy') to add the text to the clipboard.

Did this work before? Yes 60

Does this work in other browsers? Yes

Chrome version: 63.0.3212.0  Channel: canary
OS Version: 10.0
Flash Version: 

The hidden text input that the text is copied from is readonly and when we remove readonly from the textarea then adding to the clipboard also works in Chrome Canary. I tried making a reduced test case with a readonly and non-readonly textarea but in any simplified test cases the problem didn't occur for some reason.
 
Cc: ligim...@chromium.org
Labels: Needs-Triage-M63 Needs-Bisect
Cc: sc00335...@techmahindra.com
Labels: -Pri-2 -Needs-Bisect hasbisect-per-revision ReleaseBlock-Stable Triaged-ET M-62 OS-Linux OS-Mac Pri-1
Owner: hu...@opera.com
Status: Assigned (was: Unconfirmed)
Tested the issue on version 63.0.3212.0 using Ubuntu 14.04,Windows 10 and on latest canary 63.0.3213.0 using Mac 10.12.6 and is reproducible with steps mentioned in Comment#0

Manual Bisect Info:
===============
Good Build: 62.0.3166.0 
Bad Build: 62.0.3167.0

You are probably looking for a change made after 489362 (known good), but no later than 489363 (first known bad).
CHANGELOG URL:
The script might not always return single CL as suspect as some perf builds might get missing due to failure.
  https://chromium.googlesource.com/chromium/src/+log/17684e9d8dd252a678cc17989303eaf027cbb61a..7a66627f0f0a681fcf3111a9bb0f01a8e0790186

From the above change log suspecting the same

Hugo Holgersson@ - Could you please check whether this is caused with respect to your change, if not please help us in assigning it to the right owner.

Adding RB-Stable as this is a recent regression.Please remove if not the case.

Comment 3 by hu...@opera.com, Sep 12 2017

Mergedinto: 761433
Status: Duplicate (was: Assigned)
Thanks mparizeau@ for submitting this bug! I believe you see this problem because your <textarea readonly> is styled 'user-select: none'. Is that correct? That explains why you couldn't reproduce it with an unstyled <textarea readonly>. I'm trying to fix this in  Issue 761433 .


Hmm, yes it does seem like user-select is affecting things. Looking at the textarea in Chrome 60 I see the textarea has user-select: text and "Computed" tab says this is because of "user agent stylesheet". In Chrome 63 I see it has user-select: none which seems to be inheriting from its parent. If I explicitly add user-select: text to the style of the textarea then the text is able to be copied.

It looks like your fix in the other issue for readonly inputs and textareas should fix this then. Thanks for the quick update!

Sign in to add a comment