New issue
Advanced search Search tips

Issue 893448 link

Starred by 1 user

Issue metadata

Status: Unconfirmed
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux
Pri: 2
Type: Bug



Sign in to add a comment

Middle click paste behavior is completely broken (not conforming to DOM event model)

Reported by dtoybo...@gmail.com, Oct 9

Issue description

UserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/69.0.3497.81 Chrome/69.0.3497.81 Safari/537.36

Steps to reproduce the problem:
1. Open https://jsfiddle.net/d_toybox/fhgyapev/17/
2. Select some text in any apps to copy selected text into the clipboard
3. Middle click in one of the editors in the testcase.

What is the expected behavior?
If the second checkbox is checked, the selected text shouldn't be pasted into the clicked editor because middle click paste must be one of default actions of auxclick event.

What went wrong?
Chromium pastes clipboard text into clicked editor even if "auxclick" event is consumed (i.e., preventDefault() is called).

Firefox works fine but partially. Due to bad implementation of "auxclick" event of Firefox <https://bugzilla.mozilla.org/show_bug.cgi?id=1441755#c4>, web apps cannot prevent any default actions of "auxclick" event on Firefox, however, if "click" event (fired for non-primary buttons only on window and document node) is consumed, Firefox correctly prevents pasting text.

Additionally, only Chromium dispatches "paste" event only when there is no editor at clicked point. Firefox will dispatch "paste" event even in such case because of supporting CodeMirror <https://bugzilla.mozilla.org/show_bug.cgi?id=1461708>, though, web apps cannot prevent pasting text with defaultPrevented attribute value of "paste" event.

So, we (Mozilla) want to know whether Chromium's behavior is intentional.

1. Whether built-in editors of Chromium intentionally ignores defaultPrevented of auxclick event or not.
2. Whether Chromium intentionally not setting defaultPrevented value to preceding auxclick event's defaultPrevented value or not.
3. Whether Chromium intentionally dispatches "paste" event even if the preceding auxclick event is consumed or not.

Did this work before? N/A 

Does this work in other browsers? Yes

Chrome version: 69.0.3497.81  Channel: n/a
OS Version: Ubuntu 18.10
Flash Version:
 
Labels: Needs-Triage-M69
Cc: phanindra.mandapaka@chromium.org
Labels: Triaged-ET Needs-Feedback
dtoybox69@ Thanks for the issue...

As per comment #0, Tried to reproduce the issue on reported chrome 69.0.3497.81 and latest chrome 69.0.3497.100 using Ubuntu 14.04 as of now we don't have Ubuntu 18.10 to test this. Attaching screenshot for reference.
Steps:
-----
1. Launched chromium
2. Opened https://jsfiddle.net/d_toybox/fhgyapev/17/ 
3. Selected some text and copied selected text into the clipboard
4. Middle clicked in the both of the editors in the testcase > 
1.Unchecked 1st one and able to paste and 2.unchecked 2nd one able to paste and 3. checked both able to paste the copied text.
As we are able to paste the text as mentioned above three scenarios using middle mouse click

@reporter: Could you please check the process that we folowed and please let us know if anything missed from our end and requesting you to verify this issue on chrome beta 70.0.3538.54. as M-70 moved as stable very soon. Also confirm that issue specific to Ubuntu 18.10. 

Thanks...!

 

 
893448.png
219 KB View Download
I meant that when "auxclick" is consumed (i.e., the second checkbox is checked), should NOT be pasted into any editor since web apps may have already handled the middle click for another action. 
Project Member

Comment 4 by sheriffbot@chromium.org, Oct 12

Labels: -Needs-Feedback
Thank you for providing more feedback. Adding the requester to the cc list.

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

Sign in to add a comment