Note: There are a few cases of duplicates in user autocompletion which are being worked on.

Keep the firefox button lit when the window is inactive

RESOLVED FIXED in Firefox 4.0b8

Status

()

Firefox
Theme
RESOLVED FIXED
7 years ago
7 years ago

People

(Reporter: tommyjb, Assigned: dao)

Tracking

({perf})

Trunk
Firefox 4.0b8
All
Windows 7
Points:
---

Firefox Tracking Flags

(blocking2.0 betaN+)

Details

Attachments

(1 attachment)

(Reporter)

Description

7 years ago
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)
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.
(Reporter)

Comment 2

7 years ago
Thanks.  Marking as NEW.
Status: UNCONFIRMED → NEW
Ever confirmed: true
(Reporter)

Comment 3

7 years ago
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?
(Reporter)

Updated

7 years ago
blocking2.0: --- → ?
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!
--> Core::Widget, and cc'ing rob and jimm
blocking2.0: ? → betaN+
Component: Theme → Widget: Win32
Product: Firefox → Core
QA Contact: theme → win32
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?
Sorry Jim - this needs an owner!
Assignee: nobody → jmathies

Comment 8

7 years ago
I think this is fixed. I don't see it anymore.
(Reporter)

Comment 9

7 years ago
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

7 years ago
Seems like a layout reflow/repaint issue, and not really something we can fix easily based on comment 6.
Component: Widget: Win32 → Layout
QA Contact: win32 → layout

Comment 11

7 years ago
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.
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.
Keywords: perf
(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

7 years ago
(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.

Updated

7 years ago
Assignee: jmathies → shorlander
Summary: There is a delay when the Firefox Button goes active/inactive → Keep the fx button lit when the window is inactive
Duplicate of this bug: 610752
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.
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.
Summary: Keep the fx button lit when the window is inactive → Keep the firefox button lit when the window is inactive
(Assignee)

Updated

7 years ago
Assignee: shorlander → nobody
Component: Layout → Theme
Product: Core → Firefox
QA Contact: layout → theme
(Assignee)

Comment 18

7 years ago
Created attachment 489294 [details] [diff] [review]
patch

simple code removal
Assignee: nobody → dao
Status: NEW → ASSIGNED
Attachment #489294 - Flags: review?(gavin.sharp)
Attachment #489294 - Flags: review?(gavin.sharp) → review+
(Assignee)

Comment 19

7 years ago
http://hg.mozilla.org/mozilla-central/rev/b6e015e6a709
Status: ASSIGNED → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 4.0b8
You need to log in before you can comment on or make changes to this bug.