504714 - about:sessionrestore should suppress middlemouse.contentLoadURL

Status: VERIFIED FIXED

(Firefox :: Session Restore, defect)

Description

[scientus]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.6) Gecko/2009032712 Firefox/3.0.8
Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.1pre) Gecko/20090714 Shiretoko/3.5.1pre

If you middle click on a tab from session restore with middlemouse.contentLoadURL;true and a url in you clipboard the sessionrestore changes to that url and the tab you clicked on restores in a new tab

Reproducible: Always

Steps to Reproduce:
1.get to session restore
2.have middlemouse.contentLoadURL;true (default linux)
3.copy into clipboard a url
4.middle click to restore a tab
Actual Results:  
5.tab restores
6.page switches to pasted url

Expected Results:  
5.tab restores

related to bug 414345

Comment 1

[Simon Bünzli]

What happens when you middle-click a hyperlink in a regular web page? If instead of opening a new tab, the URL from the clipboard is loaded, this bug is likely WONTFIX.

Comment 2

[scientus]

This works exactly as expected on hyperlinks in a regular web page, (same as other platforms/middlemouse.contentLoadURL=false i.e. open in a new tab, no clipboard action) otherwise you would have every Linux user yelling at you.

This bug is specific to the session restore XUL page.

Comment 3

[Simon Bünzli]

Right, browser.js's contentAreaClick will have to be taught about either XUL (trees) in general or about:sessionrestore's <xul:tree id="tabList"> in particular.

Comment 4

[[:Aleksej]]

Confirmed with Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.3a1pre) Gecko/20100202 Minefield/3.7a1pre

Comment 5

[[:Aleksej]]

This still happens with Mozilla/5.0 (X11; Linux i686; rv:2.0b8pre) Gecko/20101208 Firefox/4.0b8pre

Comment 6

[u279076]

We should probably get this fixed for Firefox 4.0.  Adding a blocking? nomination.

Comment 7

[u279076]

Not a dupe, but probably related:
bug 605939

Comment 8

[Paul O'Shannessy [:zpao] (not bugmail, email directly)]

I would blocking- this if I could. Not something I would hold shipping for. That said it might be easy to fix.

Simon: Not sure how closely you're reading bugmail, but couldn't we just stop propagation if we process the middle click? A quick test seems like it's doing the right thing

Comment 9

[Paul O'Shannessy [:zpao] (not bugmail, email directly)]

Attachment: Patch v0.1

Seems to work without having to special case this particular tree

Comment 10

[Dietrich Ayala (:dietrich)]

Narrow, not holding the release for this.

Comment 11

[Dietrich Ayala (:dietrich)]

Comment on attachment 496343 [details] [diff] [review]
Patch v0.1

sounds like the simpler solution. looks fine, r=me.

Comment 12

[Paul O'Shannessy [:zpao] (not bugmail, email directly)]

Pushed http://hg.mozilla.org/mozilla-central/rev/350893cc9032

Comment 13

[George Carstoiu]

Mozilla/5.0 (X11; Linux i686; rv:7.0a1) Gecko/20110629 Firefox/7.0a1

Verified using the steps to reproduce from Comment 1 on Ubuntu 11.04, Mac OS X 10.6, Win7, WinXP.

Issue no longer reproducible -> Setting status to Verified Fixed.