The default bug view has changed. See this FAQ.

about:sessionrestore should suppress middlemouse.contentLoadURL

VERIFIED FIXED in Firefox 6

Status

()

Firefox
Session Restore
VERIFIED FIXED
8 years ago
6 years ago

People

(Reporter: scientus, Assigned: zpao)

Tracking

3.5 Branch
Firefox 6
All
Linux
Points:
---

Firefox Tracking Flags

(blocking2.0 -)

Details

(Whiteboard: [session-store-testday])

Attachments

(1 attachment)

(Reporter)

Description

8 years ago
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

8 years ago
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.
(Reporter)

Comment 2

8 years ago
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

8 years ago
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Version: unspecified → 3.5 Branch

Comment 4

7 years ago
Confirmed with Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.3a1pre) Gecko/20100202 Minefield/3.7a1pre
Whiteboard: [session-store-testday]

Comment 5

6 years ago
This still happens with Mozilla/5.0 (X11; Linux i686; rv:2.0b8pre) Gecko/20101208 Firefox/4.0b8pre
We should probably get this fixed for Firefox 4.0.  Adding a blocking? nomination.
blocking2.0: --- → ?
Not a dupe, but probably related:
bug 605939
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
Created attachment 496343 [details] [diff] [review]
Patch v0.1

Seems to work without having to special case this particular tree
Assignee: nobody → paul
Status: NEW → ASSIGNED
Attachment #496343 - Flags: review?(dietrich)
Narrow, not holding the release for this.
blocking2.0: ? → -
Summary: restore session should supress middlemouse.contentLoadURL → restore session should suppress middlemouse.contentLoadURL
Comment on attachment 496343 [details] [diff] [review]
Patch v0.1

sounds like the simpler solution. looks fine, r=me.
Attachment #496343 - Flags: review?(dietrich) → review+
Pushed http://hg.mozilla.org/mozilla-central/rev/350893cc9032
Status: ASSIGNED → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
Summary: restore session should suppress middlemouse.contentLoadURL → about:sessionrestore should suppress middlemouse.contentLoadURL
Target Milestone: --- → Firefox 6

Comment 13

6 years ago
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.
Status: RESOLVED → VERIFIED

Updated

6 years ago
Duplicate of this bug: 605939
You need to log in before you can comment on or make changes to this bug.