When a background window opens a sheet, Widget: Cocoa knows that it isn't making the window active, so the window titlebar keeps the lighter inactive color, but apparently the active attribute gets set, because the rest of the (not-so-) unified toolbar turns the darker active color. STR: 1. Load javascript:void(setTimeout("alert('foo')", 3000)); 2. Make that window inactive but still at least partly visible 3. Wait for the timeout Expected: the whole thing should stay the light inactive color, according to Camino's behavior (though even turning the whole thing dark would be better than the Actual: Palomino toolbar). (Almost certainly not a Firefox bug, since I actually noticed it in Thunderbird with the patch from bug 432568, but I'm not sure whether it's DOM, or events, or widget, or something else, so I went with bug 406730's also-wrong component.)

Firefox does it too; this URL does an alert("OMG") after a 5 second delay to demonstrate.

:( It looks like we shouldn't send activate events to the sheet if the parent window isn't activated... Steven, could you look at this?

I've noticed this as well from time to time with slow-loading popup windows or plugins; if I put the window into the background, and then the slow-loading resource activates, I get the incomplete looking title bar.

Neil, could you have a look at this?

Looks like the code is manually calling activateInWindow for some reason as if that meant the window was activated (a similar case applies to to deactivateInWindow). activateInWindow should only be called when the operating system sends us the right notification. Possibly the issue is compounded because we don't really distinguish between key and main windows. The highlighting should probably be associated with the main window but the activate/deactivate should be associated with the key window.

(In reply to comment #5) > Looks like the code is manually calling activateInWindow for some reason as if > that meant the window was activated (a similar case applies to to > deactivateInWindow). activateInWindow should only be called when the operating > system sends us the right notification. OK, I'll look at that. > Possibly the issue is compounded because we don't really distinguish between > key and main windows. The highlighting should probably be associated with the > main window but the activate/deactivate should be associated with the key > window. The code that sets the active attribute assumes that a sheet being key window is equivalent to its parent top level window being the main window, and it bases the highlighting on this implied main state. Of course that's not always correct, but making Gecko aware of the difference between main and key feels like overkill for this bug.

(In reply to comment #6) > that a sheet being key window > is equivalent to its parent top level window being the main window Only if there is a sheet, of course.

This got worse (from a user's standpoint) somewhere between Firefox Beta 7 and Beta 8. While previously tabs on top would result in the navigation toolbar and only minor details on the tabs changing, now everything from the tab bar down changes to active state. Since this now includes the background, it makes an obvious line right below the title bar when tabs are on top. While I'd personally love to see this fixed regardless, the new hard line between the title bar and the toolbar makes it very obvious something's wrong, even to less-observant users. The behavior remains unchanged for tabs on bottom.

Bug 662653 has good STR for this bug.

> Bug 662653 has good STR for this bug. And bug 662653's STR happens fairly often. Which might increase this bug's urgency ... though it's by no means critical.

Moving to p3 because no activity for at least 1 year(s). See https://github.com/mozilla/bug-handling/blob/master/policy/triage-bugzilla.md#how-do-you-triage for more information