Bugzilla

Consider this when there is a window with two tabs in it. One of the tabs is dragged out to a new window.

When it succeeds, mActiveBrowsingContextInChrome is set correctly when the tab is dragged out. The steps that are happening are:

1. WindowLowered is invoked on the tab being dragged out. SendUnsetActiveBrowsingContext is called to inform the parent process that this browsing context is no longer active. 
2. WindowLowered is invoked on the old parent process window.
3. WindowRaised is invoked on the newly created parent process window.
4. WindowRaised is invoked on the new tab that was dragged out. SendSetActiveBrowsingContext is called to inform the parent process that this browsing context is now active. 

When it fails, mActiveBrowsingContextInChrome is null after the tab is dragged out. The steps that are happening are:

1. WindowRaised is invoked on the other background tab (the one not being dragged). SendSetActiveBrowsingContext is called to inform the parent process that the browsing context for the other tab is now active. (mActiveBrowsingContextInChrome is set to the other tab)
2. WindowLowered is invoked on the tab being dragged out (which now contains a blank page)
3. WindowLowered is invoked on the old parent process window.
4. WindowLowered is invoked on the other background tab. SendUnsetActiveBrowsingContext is called to inform the parent process that the browsing context for the other tab is no longer active. (mActiveBrowsingContextInChrome is set to null)
5. WindowRaised is invoked on the new tab that was dragged out. However, nothing here informs the parent process that this browsing context is now active.

Essentially, the failure case has us trying the adjust the active browsing context in content (mActiveBrowsingContextInContent) for the process for the tab that we aren't dragging. In particular, the mActiveBrowsingContextInContent for the tab we are dragging is never modified during the tab tearoff process, so raising it at the end in step 5 just returns early at https://searchfox.org/mozilla-central/rev/e9cd2997be1071b9bb76fc14df0f01a2bd721c30/dom/base/nsFocusManager.cpp#709 even though mActiveBrowsingContextInChrome in the parent process does not match.

Consider this when there is a window with two tabs in it. One of the tabs is dragged out to a new window.

When it succeeds, mActiveBrowsingContextInChrome is set correctly when the tab is dragged out. The steps that are happening are:

1. WindowLowered is invoked on the tab being dragged out. SendUnsetActiveBrowsingContext is called to inform the parent process that this browsing context is no longer active. 
2. WindowLowered is invoked on the old parent process window.
3. WindowRaised is invoked on the newly created parent process window.
4. WindowRaised is invoked on the new tab that was dragged out. SendSetActiveBrowsingContext is called to inform the parent process that this browsing context is now active. 

When it fails, mActiveBrowsingContextInChrome is null after the tab is dragged out. The steps that are happening are:

1. WindowRaised is invoked on the other background tab (the one not being dragged). SendSetActiveBrowsingContext is called to inform the parent process that the browsing context for the other tab is now active. (mActiveBrowsingContextInChrome is set to the other tab)
2. WindowLowered is invoked on the tab being dragged out (which now contains a blank page)
3. WindowLowered is invoked on the old parent process window.
4. WindowLowered is invoked on the other background tab. SendUnsetActiveBrowsingContext is called to inform the parent process that the browsing context for the other tab is no longer active. (mActiveBrowsingContextInChrome is set to null)
5. WindowRaised is invoked on the newly created parent process window.
6. WindowRaised is invoked on the new tab that was dragged out. However, nothing here informs the parent process that this browsing context is now active.

Essentially, the failure case has us trying the adjust the active browsing context in content (mActiveBrowsingContextInContent) for the process for the tab that we aren't dragging. In particular, the mActiveBrowsingContextInContent for the tab we are dragging is never modified during the tab tearoff process, so raising it at the end in step 6 just returns early at https://searchfox.org/mozilla-central/rev/e9cd2997be1071b9bb76fc14df0f01a2bd721c30/dom/base/nsFocusManager.cpp#709 even though mActiveBrowsingContextInChrome in the parent process does not match.