Closed Bug 356005 Opened 18 years ago Closed 18 years ago

Middle click onto URL bar (address bar) icon opens a new tab

Categories

(SeaMonkey :: UI Design, defect)

1.8 Branch
x86
All
defect
Not set
minor

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: s.a.moeller, Assigned: benoit)

Details

(Keywords: fixed-seamonkey1.1)

Attachments

(1 file, 1 obsolete file)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.1b2) Gecko/20060821 SeaMonkey/1.1a
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.1b2) Gecko/20060821 SeaMonkey/1.1a

A middle click onto the URL bar icon loads the clipboard content as a web address. In SeaMonkey 1.0 and Firefox (all Versions, including 2.0 Beta 2) the URL gets loaded in the current tab, whereas in Seamonkey 1.1a and 1.5a the behaviour has changed. Now a new tab is opened. To me, this seems to be a bug.

Reproducible: Always

Steps to Reproduce:
1. Copy a web address into the clipboard.
2. Middle click onto the icon inside the URL bar.


Actual Results:  
A new tab opens.


Expected Results:  
The current tab should be used.
Assignee: general → guifeatures
Component: General → XP Apps: GUI Features
QA Contact: general
Version: unspecified → 1.8 Branch
http://lxr.mozilla.org/seamonkey/source/xpfe/communicator/resources/content/contentAreaClick.js#331
I'm guessing this check was not written with the consideration that you could middle-click the proxy icon.
Right... you'd either have to add a check that the target's binding parent (document.getBindingParent(tab)) is the tabbrowser, or add a parameter to middleMousePaste to indicate whether to check for a click on the tabbrowser.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Attached patch patch (obsolete) — Splinter Review
Made the change that Neil suggested.
Assignee: guifeatures → benoit
Status: NEW → ASSIGNED
Comment on attachment 242816 [details] [diff] [review]
patch

Sorry, this isn't right.  I can no longer middle click an empty portion of the tab strip and get a new tab now.  Neil, should he walk up the bindingparents instead of checking the immediate parent? (I assume bindingParent is ending up as button or tabs, but not tab strip).

BenoitRen, use more lines of context (diff -u9) for future patches.  It makes them more readable.
Attachment #242816 - Flags: review-
> I can no longer middle click an empty portion of the tab strip and get
> a new tab now.

???

For me, that never worked in any Mozilla based Browser. (at least on Windows)
(In reply to comment #4)
>(From update of attachment 242816 [details] [diff] [review])
>Sorry, this isn't right.  I can no longer middle click an empty portion of the
>tab strip and get a new tab now.  Neil, should he walk up the bindingparents
>instead of checking the immediate parent? (I assume bindingParent is ending up
>as button or tabs, but not tab strip).
Actually I think the binding parent of the blank spacer on the tab strip is the tab strip ;-) OK, so my next idea is to check (event.target == gBrowser).
(In reply to comment #5)
> > I can no longer middle click an empty portion of the tab strip and get
> > a new tab now.
> 
> ???
> 
> For me, that never worked in any Mozilla based Browser. (at least on Windows)
> 

Right, I was testing with contentLoadURL and middlemouse.paste set, to make sure it wouldn't break linux.
Attachment #242816 - Attachment is obsolete: true
Attachment #245512 - Flags: superreview?(neil)
Attachment #245512 - Flags: review?(cst)
OS: Windows 2000 → All
Attachment #245512 - Flags: superreview?(neil) → superreview+
Comment on attachment 245512 [details] [diff] [review]
revised and tested patch

r=me.  Remember that this needs to be applied to both xpfe and suite versions of the file when you check it in.
Attachment #245512 - Flags: review?(cst) → review+
Comment on attachment 245512 [details] [diff] [review]
revised and tested patch

Patch has baken on trunk since 17/11. Requesting approval for branch landing.
Attachment #245512 - Flags: approval-seamonkey1.1?
Comment on attachment 245512 [details] [diff] [review]
revised and tested patch

a=me for 1.1 (this is simple enough that I don't think it requires second-a)
Attachment #245512 - Flags: approval-seamonkey1.1? → approval-seamonkey1.1+
landed on branch
Status: ASSIGNED → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
Component: XP Apps: GUI Features → UI Design
You need to log in before you can comment on or make changes to this bug.