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)
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: s.a.moeller, Assigned: benoit)
Details
(Keywords: fixed-seamonkey1.1)
Attachments
(1 file, 1 obsolete file)
1.13 KB,
patch
|
csthomas
:
review+
neil
:
superreview+
csthomas
:
approval-seamonkey1.1+
|
Details | Diff | Splinter Review |
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•18 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•18 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
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•18 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•18 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.
Attachment #242816 -
Attachment is obsolete: true
Attachment #245512 -
Flags: superreview?(neil)
Attachment #245512 -
Flags: review?(cst)
Updated•18 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•18 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•18 years ago
|
||
landed on branch
You need to log in
before you can comment on or make changes to this bug.
Description
•