Exiting the new Firefox menu by clicking outside the Firefox window results in an active Firefox button on an inactive window

RESOLVED WORKSFORME

Status

()

Core
Widget: Win32
RESOLVED WORKSFORME
8 years ago
7 years ago

People

(Reporter: Hjalte, Assigned: Felipe)

Tracking

Trunk
x86
Windows 7
Points:
---

Firefox Tracking Flags

(blocking2.0 -)

Details

Attachments

(1 attachment)

(Reporter)

Description

8 years ago
User-Agent:       Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b6pre) Gecko/20100906 Firefox/4.0b6pre Firefox/4.0b6pre
Build Identifier: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b6pre) Gecko/20100906 Firefox/4.0b6pre Firefox/4.0b6pre

D2D and D3D9 enabled on the latest hourly.

Picture of active Firefox menu on inactive window: http://i51.tinypic.com/mw6q0g.jpg

Reproducible: Always

Steps to Reproduce:
1. Click on the new Firefox menu
2. Exit the menu by clicking anywhere outside the Firefox window (Taskbar, desktop, other windows)

Actual Results:  
Firefox menu remains active although the Firefox window is inactive.

Expected Results:  
Firefox menu should revert to its inactive state.
(Reporter)

Updated

8 years ago
Version: unspecified → Trunk
(Reporter)

Updated

8 years ago
Blocks: 574681

Comment 1

8 years ago
confirmed
Status: UNCONFIRMED → NEW
Ever confirmed: true
Sounds like a Win32 widget bug? :-moz-window-inactive is used extensively on OS X and I haven't heard of problems there.

Updated

8 years ago
Duplicate of this bug: 594362

Updated

8 years ago
Component: Theme → General
Product: Firefox → Core
QA Contact: theme → general

Comment 4

8 years ago
Hmm, took a shot and applied the patch in bug 593959, but it didn't seem to solve this.

Comment 5

8 years ago
(In reply to comment #2)
> Sounds like a Win32 widget bug? :-moz-window-inactive is used extensively on OS
> X and I haven't heard of problems there.

Doesn't seem to happen on any other button with a menu, so assuming we use the same methodology, it doesn't look like a widget bug. I'll have to dig into what takes place here to see.

Updated

8 years ago
blocking2.0: --- → ?
Note that I think the patch in bug 593959 needs to be updated to include hover cases as well as active cases, and the Firefox button does change colour when you hover over it when it is on an inactive window. So it could still be bug 593959.

Updated

8 years ago
blocking2.0: ? → final+
Component: General → Widget: Win32
QA Contact: general → win32
Olli, can you take a look at what Timothy said in comment 6, to see if it fixes this bug?

Also, I'm not convinced it's a blocker, but I don't want to unilaterally override Benjamin.
Assignee: nobody → Olli.Pettay

Comment 8

8 years ago
bug 593959 is about different documents. This one sounds like about
deactivating a window.

I don't have a system for windows development, but I'll try to look at this a bit.

Comment 9

8 years ago
So how do we style the Firefox button? Based on :active or 
:-moz-window-active or what?
(Assignee)

Comment 10

8 years ago
Both :active and :-moz-window-inactive are used.
This is the relevant styling: http://mxr.mozilla.org/mozilla-central/source/browser/themes/winstripe/browser/browser.css#112
So as a quickhack, would
changing #appmenu-button:hover:active
to
#appmenu-button:hover:active:not(:-moz-window-inactive)
help here?
(Assignee)

Comment 12

8 years ago
It doesn't seem to help.

I'm wondering if this is related to how the focus+activate messages are handled. The widget code expects the messages to be ordered as activate then focus. maybe in this case the messages are reversed.
So I'm now on Win7, and I can see the problem.
But for some reason the button doesn't change state immediately
when the window becomes (de)activated. 

What causes -moz-window-inactive updates?
Is it possible that some inactive message goes to the (native) widget which
controls the popup menu and not to the main window?

It would be great if someone with a system for Win7 development could look at this.
Olli, that's bug 594367.
(Assignee)

Comment 15

8 years ago
Created attachment 487007 [details] [diff] [review]
Patch

WM_ACTIVATE is consumed on DealWithPopups. It looks like there's no problem to not consume that message. (The handling of the message remains the same, it's only the flag returned to consume the event that changes)

Jim, Masayuki, any input?
Assignee: Olli.Pettay → felipc
Status: NEW → ASSIGNED
Attachment #487007 - Flags: review?
I have no idea about any new regressions by the patch, Kimura-san, how about you?

# I guess that WM_ACTIVATEAPP might have similar hidden bug.
(Assignee)

Comment 17

8 years ago
Comment on attachment 487007 [details] [diff] [review]
Patch

I sent this to tryserver and have also been using the patch for some days and didn't notice any regression. I think this change is innocuous, but it's probably better to get this in early, so setting the review flag.
Attachment #487007 - Flags: review? → review?(jmathies)
(Assignee)

Updated

8 years ago
Whiteboard: [needs review jimm]

Comment 18

8 years ago
(In reply to comment #17)
> Comment on attachment 487007 [details] [diff] [review]
> Patch
> 
> I sent this to tryserver and have also been using the patch for some days and
> didn't notice any regression. I think this change is innocuous, but it's
> probably better to get this in early, so setting the review flag.

So I guess we've removed the glass non-active state, which makes this hard to test. With this patch though I still occasionally see the hover state remain on the button. Is that supposed to be fixed by this patch as well?

Comment 19

8 years ago
One thing I did notice, this addresses a problem with active window state. (If you test on aero basic you can see the problem.) If the hover state issue isn't supposed to be part of this, I'll r+ the patch.
Whiteboard: [needs review jimm]

Updated

8 years ago
Attachment #487007 - Flags: review?(jmathies) → review+
blocking2.0: final+ → -
Is this even still an issue now that the button stays orange always?

Comment 21

8 years ago
(In reply to comment #20)
> Is this even still an issue now that the button stays orange always?

Yeah but it's subtle, the button sometimes keeps the orange hover glow.
(Assignee)

Comment 22

7 years ago
not happening anymore, probably fixed by bug 511010
Status: ASSIGNED → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.