Routing to input team for triage.

I've created a patch:
https://codereview.chromium.org/2685723005

mwrobel@, the issue should be assigned to you but it says you're not a project member. Are you going through the steps to be approved?

Do you know who might be a good reviewer for your patch? If not I can help you try to find someone.

mwrobel, in case you are not sure "the steps", you can refer to
https://www.chromium.org/developers/contributing-code

+yosin, could you review the patch?

@bokan
I'm not a project member (I just found this issue while trying to resolve a bug at opera). Sorry I forgot to find and request a review. Already done this (send review request to yosin, ojan, yutak)

The test case in #1 is incorrect. For security reasons, JS initiated copy/cut/paste (via document.execCommand) is banned in normal cases. JS is only allowed to capture user-initiated clipboard events.

According to what you described in chromium-discuss, I guess the correct repro is:
1. Open https://jsfiddle.net/uzaLwjkc/2/
2. Select any text in the link
3. Copy (via Ctrl+C or context menu)
4. Observe that 'copy' is not captured

#8

I think test case proposed in #1 is correct: 

1. spec says it should work like that: https://w3c.github.io/clipboard-apis/#to-fire-a-clipboard-event
2. it works like that in firefox (which is not a proof but just a confirmation ;))

JS initiated copy/cut/paste is not banned: when there are no shaddow roots in document, and listener is registered on document element, then event will be fired.

#10:

According to spec, clipboard events are not fired for script initiated operations (unless otherwise configured, e.g., in layout tests). See sec 8 of the spec:

https://w3c.github.io/clipboard-apis/#clipboard-actions

The algorithm you gave is irrelevant. It is for, *when clipboard event should be fired*, how to set the members of the event.

#11:

yes, my change is about *if clipboard event is fired, then set it's target according to https://w3c.github.io/clipboard-apis/#to-fire-a-clipboard-event point 6*

In chromium all script initiated operations tries to dispatch clipboard event (https://chromium.googlesource.com/chromium/src/+/master/third_party/WebKit/Source/core/editing/Editor.cpp#573). 
So when they do so, the algorithm of establishing event target (https://chromium.googlesource.com/chromium/src/+/master/third_party/WebKit/Source/core/editing/Editor.cpp#562) should be correct, and my change makes this algoright correct.

I didn't say Blink doesn't have any bug in clipboard event targets.

My point is that the test case in #1 doesn't correctly reveal the bug, as Blink's current behavior in the test case is as expected.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/7afbab0f7619c89aa7a5896024d1628a59cc0ef1

commit 7afbab0f7619c89aa7a5896024d1628a59cc0ef1
Author: mwrobel <mwrobel@opera.com>
Date: Tue Feb 21 09:34:38 2017

Make Editor::findEventTargetFrom() to align Clipboard API specification

This patch changes |Editor::findEventTargetFrom()| to return focused element if
selection start is not editable to align Clipboard API specification[1] for
improving interoperability.

[1] https://w3c.github.io/clipboard-apis/#to-fire-a-clipboard-event

BUG=690104
TEST=webkit_unittests --gtest_filter=ClipboardEventFlowTest.*

Review-Url: https://codereview.chromium.org/2685723005
Cr-Commit-Position: refs/heads/master@{#451716}

[modify] https://crrev.com/7afbab0f7619c89aa7a5896024d1628a59cc0ef1/third_party/WebKit/LayoutTests/editing/pasteboard/onpaste-text-html-types.html
[modify] https://crrev.com/7afbab0f7619c89aa7a5896024d1628a59cc0ef1/third_party/WebKit/Source/core/editing/BUILD.gn
[add] https://crrev.com/7afbab0f7619c89aa7a5896024d1628a59cc0ef1/third_party/WebKit/Source/core/editing/ClipboardEventFlowTest.cpp
[modify] https://crrev.com/7afbab0f7619c89aa7a5896024d1628a59cc0ef1/third_party/WebKit/Source/core/editing/Editor.cpp
[modify] https://crrev.com/7afbab0f7619c89aa7a5896024d1628a59cc0ef1/third_party/WebKit/Source/core/html/HTMLButtonElement.h

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/0b5fb5f6ef0d0deba7d706424cc3a05365172b1a

commit 0b5fb5f6ef0d0deba7d706424cc3a05365172b1a
Author: luoe <luoe@chromium.org>
Date: Sat Mar 11 00:29:30 2017

Revert of evaluating clipboard event target acording to w3c specification (patchset #7 id:120001 of https://codereview.chromium.org/2685723005/ )

Reason for revert:
Changing this functionality improved spec conformance, but introduced regressions where text that used to be copied is no longer copied:
 crbug.com/695568 
 crbug.com/700163 

A proposal to change the spec was made here:
https://github.com/w3c/clipboard-apis/issues/40

Original issue's description:
> Make Editor::findEventTargetFrom() to align Clipboard API specification
>
> This patch changes |Editor::findEventTargetFrom()| to return focused element if
> selection start is not editable to align Clipboard API specification[1] for
> improving interoperability.
>
> [1] https://w3c.github.io/clipboard-apis/#to-fire-a-clipboard-event
>
> BUG=690104
> TEST=webkit_unittests --gtest_filter=ClipboardEventFlowTest.*
>
> Review-Url: https://codereview.chromium.org/2685723005
> Cr-Commit-Position: refs/heads/master@{#451716}
> Committed: https://chromium.googlesource.com/chromium/src/+/7afbab0f7619c89aa7a5896024d1628a59cc0ef1

TBR=tkent@chromium.org,ojan@chromium.org,yosin@chromium.org,yutak@chromium.org,sigbjornf@opera.com,mwrobel@opera.com
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=690104

Review-Url: https://codereview.chromium.org/2745813002
Cr-Commit-Position: refs/heads/master@{#456232}

[modify] https://crrev.com/0b5fb5f6ef0d0deba7d706424cc3a05365172b1a/third_party/WebKit/LayoutTests/editing/pasteboard/onpaste-text-html-types.html
[modify] https://crrev.com/0b5fb5f6ef0d0deba7d706424cc3a05365172b1a/third_party/WebKit/Source/core/editing/BUILD.gn
[delete] https://crrev.com/d62ba1f5529bb7bfa48ea80ea131c1b9fd0f17b6/third_party/WebKit/Source/core/editing/ClipboardEventFlowTest.cpp
[modify] https://crrev.com/0b5fb5f6ef0d0deba7d706424cc3a05365172b1a/third_party/WebKit/Source/core/editing/Editor.cpp
[modify] https://crrev.com/0b5fb5f6ef0d0deba7d706424cc3a05365172b1a/third_party/WebKit/Source/core/html/HTMLButtonElement.h

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/ea1abaf0d7e6c26dc323607901c91b27a72e4979

commit ea1abaf0d7e6c26dc323607901c91b27a72e4979
Author: luoe <luoe@chromium.org>
Date: Tue Mar 14 03:44:52 2017

Revert of evaluating clipboard event target acording to w3c specification (patchset #7 id:120001 of https://codereview.chromium.org/2685723005/ )

Reason for revert:
Changing this functionality improved spec conformance, but introduced regressions where text that used to be copied is no longer copied:
 crbug.com/695568 
 crbug.com/700163 

A proposal to change the spec was made here:
https://github.com/w3c/clipboard-apis/issues/40

Original issue's description:
> Make Editor::findEventTargetFrom() to align Clipboard API specification
>
> This patch changes |Editor::findEventTargetFrom()| to return focused element if
> selection start is not editable to align Clipboard API specification[1] for
> improving interoperability.
>
> [1] https://w3c.github.io/clipboard-apis/#to-fire-a-clipboard-event
>
> BUG=690104
> TEST=webkit_unittests --gtest_filter=ClipboardEventFlowTest.*
>
> Review-Url: https://codereview.chromium.org/2685723005
> Cr-Commit-Position: refs/heads/master@{#451716}
> Committed: https://chromium.googlesource.com/chromium/src/+/7afbab0f7619c89aa7a5896024d1628a59cc0ef1

TBR=tkent@chromium.org,ojan@chromium.org,yosin@chromium.org,yutak@chromium.org,sigbjornf@opera.com,mwrobel@opera.com
BUG=690104
NOTRY=true
NOPRESUBMIT=true

Review-Url: https://codereview.chromium.org/2745813002
Cr-Commit-Position: refs/heads/master@{#456232}
(cherry picked from commit 0b5fb5f6ef0d0deba7d706424cc3a05365172b1a)

Review-Url: https://codereview.chromium.org/2745353002
Cr-Commit-Position: refs/branch-heads/3029@{#179}
Cr-Branched-From: 939b32ee5ba05c396eef3fd992822fcca9a2e262-refs/heads/master@{#454471}

[modify] https://crrev.com/ea1abaf0d7e6c26dc323607901c91b27a72e4979/third_party/WebKit/LayoutTests/editing/pasteboard/onpaste-text-html-types.html
[modify] https://crrev.com/ea1abaf0d7e6c26dc323607901c91b27a72e4979/third_party/WebKit/Source/core/editing/BUILD.gn
[delete] https://crrev.com/1d5b89e176f0346c84cd18e2e5934619b427246f/third_party/WebKit/Source/core/editing/ClipboardEventFlowTest.cpp
[modify] https://crrev.com/ea1abaf0d7e6c26dc323607901c91b27a72e4979/third_party/WebKit/Source/core/editing/Editor.cpp
[modify] https://crrev.com/ea1abaf0d7e6c26dc323607901c91b27a72e4979/third_party/WebKit/Source/core/html/HTMLButtonElement.h

Tested this issue on Windows 7 using chrome #58.0.3029.33  as per the below steps:
1.Downloaded the given html file in comment#1.
2.Opened the file in chrome browser
3.Observed "'clipboard event not fired yet!'" text & 'Test' buttons displayed on load
4.Click on 'Test' button
5.Observed no change in the text ("'clipboard event not fired yet!'" text displayed which is not intended behaviour)

Seems issue not yet fixed.Please find the attached screencast for reference.
Could you please check the issue & confirm on the fix.

Thank you!!

Deleted: 690104_win.mp4 593 KB

	690104_win.mp4 593 KB View Download

I think you can close this issue because:

instead of aligning with clipboard API specification (patch https://chromium.googlesource.com/chromium/src/+/7afbab0f7619c89aa7a5896024d1628a59cc0ef1), decision was to request to align clipboard API specification with current implementation (https://github.com/w3c/clipboard-apis/issues/40).
More details in discussion in here https://bugs.chromium.org/p/chromium/issues/detail?id=700163&desc=2#c19

If specification will be changed (according to second proposal in https://github.com/w3c/clipboard-apis/issues/40), this will be desired behaviour.

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot