Bugzilla

(In reply to Neil Deakin from comment #40)
> I think an analysis of what the callers are doing when getting the active window would be needed. Many callers just want to know whether they are inside an active window so they can update UI state (window decorations, highlight colours, etc). Those don't actually need to know which window is active, but just a boolean indicating active versus inactive. Much of the rest are chrome process only so the issue wouldn't apply. Are there any content process uses of the active window that do more than that?

AFAICT, there are three cases:

1. Checking if current focus or about-to-be-focused thing is in the frontmost GUI window (and for Web content, tab). 
2. Checking things related to actual native GUI window raisedness in the chrome process only.
3. Checking things related to either the actual native GUI window raisedness in the chrome process _or_ raisedness of a process boundary integration point in a content process.

For the purpose of item #1 it should logically be enough to track the `BrowsingContext` that is in the frontmost GUI window _and_ has focus, since it should be always possible to walk up from that one. However, doing only that totally breaks cases #2 and #3, because the relationship between "focused" and "active" gets out of sync during raising a window. Specifically, the code wants the window being raised to become "active" synchronously, and then activation / pseudo-raise asynchronously propagates down.

The async top-down propagation is fine for switching tabs/windows from the top and for sequential tabbing, but, as noted, it doesn't at all fit the notion that a random at the bottom wants to get focused bottom-up. For the start of the bottom-up focusing action, checking what's allowed and what needs to happen, it should be enough for the content process to have an ahead-of-time eagerly-synced copy of the `BrowsingContext` tree as well as the currently-focused `BrowsingContext`. However, getting everything else in the right state afterwards, considering that things are built to sync top-down is unresolved. (Hand-waved in comment 14, but in addition to running blurring, the end state should get the "active" status of everything right.)

> If however the descendant A subframe was focused, nsFocusedManager::mFocusedWindow would be the lower A, and nsFocusedManager::mFocusedElement would be whatever element in that was focused. The ancestor A's nsPIDOMWindow::mFocusedElement would point at the subframe.

Right, but I'm not yet convinced that there isn't an assumption that when processing things related to the ancestor A, `nsFocusedManager::mFocusedElement` should point to the subframe (which it can't, since the global is pointing to something in the descendant A).

(In reply to Neil Deakin from comment #40)
> I think an analysis of what the callers are doing when getting the active window would be needed. Many callers just want to know whether they are inside an active window so they can update UI state (window decorations, highlight colours, etc). Those don't actually need to know which window is active, but just a boolean indicating active versus inactive. Much of the rest are chrome process only so the issue wouldn't apply. Are there any content process uses of the active window that do more than that?

AFAICT, there are three cases:

1. Checking if current focus or about-to-be-focused thing is in the frontmost GUI window (and for Web content, tab). 
2. Checking things related to actual native GUI window raisedness in the chrome process only.
3. Checking things related to either the actual native GUI window raisedness in the chrome process _or_ raisedness of a process boundary integration point in a content process.

For the purpose of item #1 it should logically be enough to track the `BrowsingContext` that is in the frontmost GUI window _and_ has focus, since it should be always possible to walk up from that one. However, doing only that totally breaks cases #2 and #3, because the relationship between "focused" and "active" gets out of sync during raising a window. Specifically, the code wants the window being raised to become "active" synchronously, and then activation / pseudo-raise asynchronously propagates down.

The async top-down propagation is fine for switching tabs/windows from the top and for sequential tabbing, but, as noted, it doesn't at all fit the notion that a random element at the bottom wants to get focused bottom-up. For the start of the bottom-up focusing action, checking what's allowed and what needs to happen, it should be enough for the content process to have an ahead-of-time eagerly-synced copy of the `BrowsingContext` tree as well as the currently-focused `BrowsingContext`. However, getting everything else in the right state afterwards, considering that things are built to sync top-down is unresolved. (Hand-waved in comment 14, but in addition to running blurring, the end state should get the "active" status of everything right.)

> If however the descendant A subframe was focused, nsFocusedManager::mFocusedWindow would be the lower A, and nsFocusedManager::mFocusedElement would be whatever element in that was focused. The ancestor A's nsPIDOMWindow::mFocusedElement would point at the subframe.

Right, but I'm not yet convinced that there isn't an assumption that when processing things related to the ancestor A, `nsFocusedManager::mFocusedElement` should point to the subframe (which it can't, since the global is pointing to something in the descendant A).