Closed
Bug 888353
Opened 11 years ago
Closed 11 years ago
Work - Middle-click or Control-click should open link in new tab
Categories
(Firefox for Metro Graveyard :: Browser, defect, P2)
Tracking
(Not tracked)
RESOLVED
FIXED
Firefox 28
People
(Reporter: kristoffer.melin, Assigned: mbrubeck)
References
Details
(Whiteboard: feature=work)
Attachments
(1 file, 2 obsolete files)
18.89 KB,
patch
|
mbrubeck
:
review+
|
Details | Diff | Splinter Review |
User Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:25.0) Gecko/20130628 Firefox/25.0 (Nightly/Aurora) Build ID: 20130628031149 Steps to reproduce: I hovered a link from a list of Google searches and used my mouse's scroll wheel to "middle-click" the hyperlink. Actual results: Nothing; literally. Expected results: As a Firefox standard, the hyperlink should have opened in a new tab.
Right-clicking the hyperlink and choosing "Open in New Tab" works fine.
Updated•11 years ago
|
Blocks: metrov1triage
Updated•11 years ago
|
Whiteboard: [metrotestday-20130628]
Updated•11 years ago
|
Priority: -- → P2
Comment 2•11 years ago
|
||
Odd bug, over in Content.js, we aren't receiving middle-click events in our click handlers. We could deal with this there but we'll need to figure out why these events never get to the front end. There's a pref we should honor as well - "browser.tabs.opentabfor.middleclick".
Updated•11 years ago
|
Component: Metro Operations → Browser
Product: Tracking → Firefox for Metro
Version: --- → Trunk
Comment 3•11 years ago
|
||
I figured this is probably just widget winrt input code, although I haven't tried using -metrodesktop for the win32 layer.
Updated•11 years ago
|
Summary: Firefox Metro cannot open links with middle-click → Defect - Firefox Metro cannot open links with middle-click
Whiteboard: [metrotestday-20130628] → [metrotestday-20130628] feature=defect c=tbd u=tbd p=0
Comment 4•11 years ago
|
||
I tested with --metrodesktop and we don't seem to get middle clicks in that environment, either, so it seems like there's a problem that's unrelated to widget. Is this a regression? I think I remember being able to middle-click on links in metro
Comment 5•11 years ago
|
||
(In reply to Tim Abraldes [:TimAbraldes] [:tabraldes] from comment #4) > I tested with --metrodesktop and we don't seem to get middle clicks in that > environment, either, so it seems like there's a problem that's unrelated to > widget. Yup sounds like not widget, thanks for checking. (I'm on a laptop :))
Comment 6•11 years ago
|
||
Yeah it's not widget, middle click to scroll works.
Updated•11 years ago
|
Summary: Defect - Firefox Metro cannot open links with middle-click → Work - Firefox Metro cannot open links with middle-click
Whiteboard: [metrotestday-20130628] feature=defect c=tbd u=tbd p=0 → [metrotestday-20130628] feature=work c=tbd u=tbd p=0
Updated•11 years ago
|
No longer blocks: metrov1defect&change
Whiteboard: [metrotestday-20130628] feature=work c=tbd u=tbd p=0 → [metrotestday-20130628] feature=work
Shouldn't the same thing work for Ctrl+Click? Holding Ctrl+clicking on hyperlink should open it in a new tab in the background.
Updated•11 years ago
|
Summary: Work - Firefox Metro cannot open links with middle-click → Defect - Firefox Metro cannot open links with middle-click
Whiteboard: [metrotestday-20130628] feature=work → [preview-triage] feature=defect c=tbd u=tbd p=0
Updated•11 years ago
|
Updated•11 years ago
|
Whiteboard: [preview-triage] feature=defect c=tbd u=tbd p=0 → [fx27-triage] feature=defect c=tbd u=tbd p=0
Assignee | ||
Updated•11 years ago
|
Hardware: x86_64 → All
Summary: Defect - Firefox Metro cannot open links with middle-click → Work - Middle-click or Control-click should open link in new tab
Whiteboard: [fx27-triage] feature=defect c=tbd u=tbd p=0 → feature=work
Assignee | ||
Comment 9•11 years ago
|
||
I know we deprioritized mouse stuff in favor of touch for v1, but this has become a top dogfooding annoyance for me, and I'm off the clock today. :) Also, ctrl-tap works for touch and pen as well.
Comment 10•11 years ago
|
||
Comment on attachment 829826 [details] [diff] [review] patch Review of attachment 829826 [details] [diff] [review]: ----------------------------------------------------------------- Thanks for doing this, a major annoyance for mouse users! Didn't even know that shift makes the new tab open in foreground, nice. Middle mouse click is not working for me, added some logging to ClickEventHandler.handleEvent() and it's not even being called. Not sure if it's related to my hardware or something local. CTRL click works great.
Attachment #829826 -
Flags: review?(rsilveira) → review+
Assignee | ||
Comment 11•11 years ago
|
||
(In reply to Rodrigo Silveira [:rsilveira] from comment #10) > Middle mouse click is not working for me, added some logging to > ClickEventHandler.handleEvent() and it's not even being called. Not sure if > it's related to my hardware or something local. CTRL click works great. Darn, you're right. I was developing this on a laptop over the weekend, and hadn't tested it with a three-button mouse yet. I'll see if I can fix that before landing.
Assignee | ||
Comment 12•11 years ago
|
||
Fixed the middle button issue and rebased. Carrying r=rsilveira. "click" events for middle- and right-click are not reaching my system event listeners in content.js, though mousedown and mouseup events work just fine. Moving the code to browser.js magically fixed this, though I'm not sure why. I'll file a follow-up bug to get this working in content.js for e10s compatibility.
Attachment #829826 -
Attachment is obsolete: true
Attachment #830998 -
Flags: review+
Assignee | ||
Updated•11 years ago
|
Keywords: checkin-needed
Assignee | ||
Comment 13•11 years ago
|
||
Jim pointed out that 3 seconds is too long a timeout for peekTabs when opening a foreground tab. This changes the timeout back to 1 second for foreground tabs, and uses the 3-second timeout for background tabs only.
Attachment #830998 -
Attachment is obsolete: true
Attachment #831034 -
Flags: review+
Assignee | ||
Comment 14•11 years ago
|
||
https://tbpl.mozilla.org/?tree=Try&rev=60c2bef69a96
Assignee | ||
Updated•11 years ago
|
Keywords: checkin-needed
Assignee | ||
Comment 15•11 years ago
|
||
https://hg.mozilla.org/integration/fx-team/rev/91682d737deb
Comment 16•11 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/91682d737deb
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → Firefox 28
Comment 17•11 years ago
|
||
I still have this issue on 27.0a2 2013-11-21.
Assignee | ||
Comment 18•11 years ago
|
||
(In reply to Dmitrij D. Czarkoff from comment #17) > I still have this issue on 27.0a2 2013-11-21. This is fixed in Firefox 28, currently on the Nightly channel. It will be fixed on Aurora when Firefox 28 moves to the Aurora channel, about three weeks from today. If you'd like to help us test the fix today, you can download Nightly from: http://nightly.mozilla.org/
Comment 19•11 years ago
|
||
(In reply to Matt Brubeck (:mbrubeck) from comment #18) > This is fixed in Firefox 28, currently on the Nightly channel. Indeed, sorry for noise. (I fooled myself into believing that Aurora is Firefox nightly, and now after installing Nightly I see the bug fixed.)
Updated•10 years ago
|
OS: Windows 8 Metro → Windows 8.1
You need to log in
before you can comment on or make changes to this bug.
Description
•