Firefox does it too; this URL does an alert("OMG") after a 5 second delay to demonstrate.
Assignee: nobody → joshmoz
Component: OS Integration → Widget: Cocoa
Product: Firefox → Core
QA Contact: os.integration → cocoa
Hardware: PC → All
:( 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.
You need to log in before you can comment on or make changes to this bug.