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)

All
Windows 8.1
defect

Tracking

(Not tracked)

RESOLVED FIXED
Firefox 28

People

(Reporter: kristoffer.melin, Assigned: mbrubeck)

References

Details

(Whiteboard: feature=work)

Attachments

(1 file, 2 obsolete files)

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.
OS: All → Windows 8 Metro
Hardware: All → x86_64
Right-clicking the hyperlink and choosing "Open in New Tab" works fine.
Whiteboard: [metrotestday-20130628]
Blocks: metrov1defect&change
No longer blocks: metrov1triage
Priority: -- → P2
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".
Component: Metro Operations → Browser
Product: Tracking → Firefox for Metro
Version: --- → Trunk
I figured this is probably just widget winrt input code, although I haven't tried using -metrodesktop for the win32 layer.
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
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
(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 :))
Yeah it's not widget, middle click to scroll works.
Blocks: 890010
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
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.
Blocks: metrov1backlog
No longer blocks: 890010
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
Blocks: metrov2defect&change
No longer blocks: metrov1backlog
Whiteboard: [preview-triage] feature=defect c=tbd u=tbd p=0 → [fx27-triage] feature=defect c=tbd u=tbd p=0
Blocks: 890010
No longer blocks: metrov2defect&change
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
Attached patch patch (obsolete) — Splinter Review
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.
Assignee: nobody → mbrubeck
Status: NEW → ASSIGNED
Attachment #829826 - Flags: review?(rsilveira)
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+
(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.
Attached patch patch v2 (obsolete) — Splinter Review
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+
Keywords: checkin-needed
Blocks: 937794
Attached patch patch v3Splinter Review
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+
Keywords: checkin-needed
https://hg.mozilla.org/mozilla-central/rev/91682d737deb
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → Firefox 28
Depends on: 941393
I still have this issue on 27.0a2 2013-11-21.
(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/
(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.)
Depends on: 943388
OS: Windows 8 Metro → Windows 8.1
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: