986845 - [e10s] Middle-clicking a link also tries to paste

Status: RESOLVED FIXED

(Firefox :: General, defect)

Description

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

If you middle-click a link, the paste action (which navigates to the URL in the clipboard) should be canceled. It's not.

Comment 1

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

This happens on Linux by default. I think it should be reproducible by setting the middlemouse.paste pref to true on other OSes. You also need something in the clipboard, of course.

Comment 2

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

Attachment: middle-click-paste

This turned out to be pretty simple. In e10s, we don't want to run the code for contentAreaClick because we have a separate way to do it. For some reason we add the contentAreaClick event handler in two places: once in gBrowserInit.onload and once on the tabbrowser element in browser.xul. The first one we correctly disable when e10s is on. The second one we don't, and that's why the middle click paste was happening.

Comment 3

[:Felipe Gomes (needinfo for replies!)]

Unfocused: this came from one of the Australis' big merges, but it was mentioned on IRC that maybe you recall :) It appears we have two tabbrowser listeners for contentAreaClick, one at:

http://hg.mozilla.org/mozilla-central/annotate/b79c2995d25e/browser/base/content/browser.js#l769
and the other at:
http://hg.mozilla.org/mozilla-central/annotate/b79c2995d25e/browser/base/content/browser.xul#l1078

Do you think it's just a bug, or is there a reason why it's like that?  I'm guessing we can remove one of the two without any probs

Comment 4

[Blair McBride [:Unfocused] (UNAVAILABLE)]

Seems this was the unintentional result of a bad merge. When we moved things around in browser.xul in bug 770135, patch inadvertently didn't take into account the change bug 748740 made to remove contentAreaClick from browser.xul.

So this part of the changeset from bug 748740 needs to be re-applied:
http://hg.mozilla.org/mozilla-central/diff/eb01f41e077b/browser/base/content/browser.xul

Comment 5

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

Attachment: middle-click-paste v2

Comment 6

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/f4a358a0f00d

Comment 7

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/f4a358a0f00d

Comment 8

[Francesca Ciceri [:madamezou]]

Hi, 

I wasn't able to reproduce it in order to verify the fix, in Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Firefox/31.0 ID:20140322030204 CSet: 72c2f9ebf4bc on Debian Sid.
These are the steps I've followed to reproduce it:

1. open e10s
2. copy something in the clipboard (select some text, right click on it → Copy)
3. click on a link with the middle button of the mouse (well, the touchpad in my case)

Athe link is opened in a new tab, unfocused, and the text copied in clipboard is not pasted anywhere

What I'm missing here? :)

As said, I'm using Debian Sid and Awesome as window manager.
Cheers,
Francesca

Comment 9

[Francesca Ciceri [:madamezou]]

(In reply to Francesca Ciceri [:madamezou] from comment #8)

> Athe link is opened in a new tab, unfocused, and the text copied 

*As a result, the link...

(sorry, sent it accidentally while I was still writing)