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.

Thanks. Marking as NEW.

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?

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

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!

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

I still see it in the latest nightly: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b7pre) Gecko/20101006 Firefox/4.0b7pre

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

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.

(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?

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

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.

simple code removal