The default bug view has changed. See this FAQ.

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

RESOLVED FIXED

Status

SeaMonkey
UI Design
--
minor
RESOLVED FIXED
11 years ago
9 years ago

People

(Reporter: Stefan A. Möller, Assigned: Benoît)

Tracking

({fixed-seamonkey1.1})

1.8 Branch
x86
All
fixed-seamonkey1.1

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 1 obsolete attachment)

1.13 KB, patch
Chris Thomas (CTho) [formerly cst@andrew.cmu.edu cst@yecc.com]
: review+
neil@parkwaycc.co.uk
: superreview+
Chris Thomas (CTho) [formerly cst@andrew.cmu.edu cst@yecc.com]
: approval-seamonkey1.1+
Details | Diff | Splinter Review
(Reporter)

Description

11 years ago
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.

Updated

11 years ago
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.

Comment 2

11 years ago
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
(Assignee)

Comment 3

11 years ago
Created attachment 242816 [details] [diff] [review]
patch

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-
(Reporter)

Comment 5

11 years ago
> 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)

Comment 6

11 years ago
(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.
(Assignee)

Comment 8

11 years ago
Created attachment 245512 [details] [diff] [review]
revised and tested patch
Attachment #242816 - Attachment is obsolete: true
Attachment #245512 - Flags: superreview?(neil)
Attachment #245512 - Flags: review?(cst)
(Assignee)

Updated

11 years ago
OS: Windows 2000 → All

Updated

11 years ago
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+
(Assignee)

Comment 10

11 years ago
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+

Comment 12

11 years ago
landed on branch
Status: ASSIGNED → RESOLVED
Last Resolved: 11 years ago
Keywords: fixed-seamonkey1.1
Resolution: --- → FIXED

Updated

9 years ago
Component: XP Apps: GUI Features → UI Design
You need to log in before you can comment on or make changes to this bug.