Closed Bug 590035 Opened 12 years ago Closed 12 years ago

Middle clicking tab bar with Menu Bar disabled doesn't open new tab

Categories

(Firefox :: General, defect)

x86
Windows 7
defect
Not set
normal

Tracking

()

RESOLVED FIXED
Firefox 4.0b7
Tracking Status
blocking2.0 --- final+

People

(Reporter: imradyurrad, Assigned: Felipe)

References

Details

(Keywords: regression)

Attachments

(1 file, 1 obsolete file)

User-Agent:       Mozilla/5.0 (Windows NT 6.1; rv:2.0b5pre) Gecko/20100822 Minefield/4.0b5pre
Build Identifier: Mozilla/5.0 (Windows NT 6.1; rv:2.0b5pre) Gecko/20100822 Minefield/4.0b5pre

When the menu bar's disabled, middle clicking on the tab bar no longer opens a new tab.

Reproducible: Always
Blocks: 555081
Depends on: 575248
Should be easy, taking
Assignee: nobody → felipc
Status: UNCONFIRMED → ASSIGNED
blocking2.0: --- → ?
Ever confirmed: true
Keywords: regression
Mostly blocking because of bug 575248, and because I think we should be careful to restore all old tabstrip functionality.
blocking2.0: ? → final+
Attached patch Patch (obsolete) — Splinter Review
We need to generate the gecko middle click events for NC middle-clicks too. I don't think there's any reason to not always do that, so here's a patch.
Attachment #471266 - Flags: review?(jmathies)
Hmm, why does this fix this? I wouldn't think windows would be sending nc mouse events for the new client/content area. (it's not an nc area anymore.)

I'm mostly just curious, did you test this? My middle click on a tab closes it. Middle click on the tab bar area does nothing.
That's because the empty area on the tabbar is considered NC area (to allow aero dragging/dbl clicking)
(In reply to comment #4)
> Hmm, why does this fix this? I wouldn't think windows would be sending nc mouse
> events for the new client/content area. (it's not an nc area anymore.)

I missed the last phrase, why do you mean it's not NC area anymore? That's what NS_MOZ_HITTEST is meant to return (I think) on the empty glass areas (e.g. the parts of the tabbar where there are no tabs)
(In reply to comment #6)
> (In reply to comment #4)
> > Hmm, why does this fix this? I wouldn't think windows would be sending nc mouse
> > events for the new client/content area. (it's not an nc area anymore.)
> 
> I missed the last phrase, why do you mean it's not NC area anymore? That's what
> NS_MOZ_HITTEST is meant to return (I think) on the empty glass areas (e.g. the
> parts of the tabbar where there are no tabs)

Ah, so we return the nc constant in WM_NCHITTEST and windows generates the appropriate mouse events. That explains why bug 574859 works on non-nc events. 

What about the middle nc double click message? Do we need that as well?
Comment on attachment 471266 [details] [diff] [review]
Patch

True, M double click is not used but should be supported
Attachment #471266 - Attachment is obsolete: true
Attachment #471266 - Flags: review?(jmathies)
Attached patch Patch v2Splinter Review
Now with double click too
Attachment #471294 - Flags: review?(jmathies)
Attachment #471294 - Flags: review?(jmathies) → review+
http://hg.mozilla.org/mozilla-central/rev/29c3f6e7c48e
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 4.0b6
You need to log in before you can comment on or make changes to this bug.