Opening a sheet in an inactive window incorrectly sets the active attribute, turns the toolbar half-dark

NEW
Unassigned

Status

()

P2
normal
11 years ago
8 years ago

People

(Reporter: philor, Unassigned)

Tracking

Trunk
All
Mac OS X
Points:
---
Dependency tree / graph
Bug Flags:
wanted1.9.0.x +

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

11 years ago
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.
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.
Flags: wanted1.9.0.x?
Priority: -- → P2

Updated

11 years ago
Flags: wanted1.9.0.x? → wanted1.9.0.x+

Updated

10 years ago
Assignee: joshmoz → nobody
Neil, could you have a look at this?

Comment 5

9 years ago
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.
Duplicate of this bug: 635444

Comment 9

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

Updated

8 years ago
Duplicate of this bug: 662653
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.