594367 - Keep the firefox button lit when the window is inactive

Status: RESOLVED FIXED

(Firefox :: Theme, defect)

Description

[tommyjb]

Windows 7 users:

1) Un-maximise a window.
2) Un-focus the window (by, for example, clicking the desktop).

Now the Firefox Button goes gray, but there is a visible delay (of about 100ms).

3) Re-focus the window (by clicking it).

Now the Firefox Button goes orange, but again there is a visible delay.  This time it's about 200ms.

(Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b6pre) Gecko/20100908 Firefox/4.0b6pre)

Comment 1

[Asbjørn Riis-Knudsen]

Confirmed. This does look awkward. And mind you, I'm running a Core 2 Quad, 8 GB RAM, a GTX 280 and Win 7 x64.

Comment 2

[tommyjb]

Thanks.  Marking as NEW.

Comment 3

[tommyjb]

The problem can be exaggerated with the following steps:

1) Un-maximise a window.
2) Un-focus the window (by, for example, clicking the desktop).
3) Re-focus the window by clicking on the title bar --- but don't release the mouse button.  Also, don't move the mouse.

Now there is a very visible delay before the Firefox Button goes orange.

This whole thing looks really unprofessional.  Would it be reasonable for me to request blocking2.0?

Comment 4

[Stephen Horlander [:shorlander]]

Robert or David:

Any ideas on why this is happening? Any known issues with delays on focus or problems with using :-moz-window-inactive for styling chrome?

Thanks!

Comment 5

[Mike Beltzner [:beltzner, not reading bugmail]]

--> Core::Widget, and cc'ing rob and jimm

Comment 6

[:Felipe Gomes (needinfo for replies!)]

Not sure what can be done to speed this up. Widget calls into nsGlobalWindow::ActivateOrDeactivate, which leads to here:

http://mxr.mozilla.org/mozilla-central/source/layout/base/nsPresShell.cpp#4986

The comment there says that this case needs to restyle the sub-tree and invalidate the whole window.

Dbaron might have some ideas?

Comment 7

[Joe Drew (not getting mail)]

Sorry Jim - this needs an owner!

Comment 8

[Jim Mathies [:jimm]]

I think this is fixed. I don't see it anymore.

Comment 9

[tommyjb]

I still see it in the latest nightly:

Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b7pre) Gecko/20101006 Firefox/4.0b7pre

Comment 10

[Jim Mathies [:jimm]]

Seems like a layout reflow/repaint issue, and not really something we can fix easily based on comment 6.

Comment 11

[Boris Zbarsky [:bzbarsky]]

Does flushing restyles after the PostRestyleEvent call make things faster, by chance?  It might if the layer invalidation stuff is actually relevant to this button...  The "don't move the mouse" thing from comment 3 makes it sound like it might be.

Comment 12

[Mike Beltzner [:beltzner, not reading bugmail]]

I don't really care if we can fix it easily. We need to fix it, or otherwise mitigate it, even if that means backing out the change which turns the button transparent when the window isn't focused. It's a noticeable delay and affects perception of performance.

Comment 13

[Stephen Horlander [:shorlander]]

(In reply to comment #12)
> I don't really care if we can fix it easily. We need to fix it, or otherwise
> mitigate it, even if that means backing out the change which turns the button
> transparent when the window isn't focused. It's a noticeable delay and affects
> perception of performance.

After talking about this with UX we decided reverting this to not go transparent when inactive would be best. It won't feel slow and it will keep the Firefox window identifiable even when inactive.

Should I make a patch that removes the inactive state for this bug or make a new bug that does that?

Comment 14

[Jim Mathies [:jimm]]

(In reply to comment #13)
> (In reply to comment #12)
> > I don't really care if we can fix it easily. We need to fix it, or otherwise
> > mitigate it, even if that means backing out the change which turns the button
> > transparent when the window isn't focused. It's a noticeable delay and affects
> > perception of performance.
> 
> After talking about this with UX we decided reverting this to not go
> transparent when inactive would be best. It won't feel slow and it will keep
> the Firefox window identifiable even when inactive.
> 
> Should I make a patch that removes the inactive state for this bug or make a
> new bug that does that?

Might as well post it here, we can morph this one to match.

Comment 16

[Alex Faaborg [:faaborg] (Firefox UX)]

Copying a comment over from a dupe:

When the window does not have the focus, we shift the Firefox button from being
orange to being transparent glass.  This is consistent with the behavior of the
close button (which shifts from being red to being transparent glass). 
However, I think that we should keep the Firefox button orange for the
following reasons:

-It will be easier for users to identify the Firefox window with their
peripheral vision: there isn't a lot of color used in Windows 7, and the orange
is a good visual cue for finding a particular background window

-Consistency with the file menu controls in office 2010, and other ribbon
applications.  These applications keep a solid color to identify the app (blue
= word, green=excel), and this color doesn't change based on the application
being focused.  Now of course they aren't placing their controls in the title
bar and on glass, but outside of control placement it seems inconsistent that
we are losing our recognizable color and they are keeping theirs.

-There's a slight delay with the button switching states when the window gain
or loses focus.  We could likely fix this, but this change would solve that
problem implicitly since we would never change state.

Comment 17

[Benjamin Smedberg]

FWIW, this could well affect extension-compat for both of my aero extensions (title bar, and iconic firefox menu), so I'd love this to be sorted out ASAP.

Comment 18

[Dão Gottwald [:dao]]

Attachment: patch

simple code removal

Comment 19

[Dão Gottwald [:dao]]

http://hg.mozilla.org/mozilla-central/rev/b6e015e6a709