Bug 1562796 Comment 3 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

> This is broader than just the Google Japanese IME. Also applies to Microsoft IMEs and not just for Japanese.

Correction: The other IMEs are affected by the steps to reproduce only if the Google IME has been previously active during the lifetime of the Firefox process. Weird. However, with other IMEs, the problem can be reproduced by placing focus in address bar, raising another window and then raising the window whose focus is in the address bar.

So the problem seems to be that the code assumes that newly-created windows initially focus a `BrowserParent`, which is the case I observed when I was writing the code prior to bug 1549930. (Now I'm curious _why_ I observed that case and not the case seen here.)

The null `BrowserParent`, i.e. browser chrome is never pushed. Getting the stack in the state that represents chrome focus requires pops. The fix for bug 1549930 suppressed pops for `BrowserParent`s in a window being lowered. That fix also accidentally assumes that in the window being raised, focus is in Web content so a push occurs. When the focus is in chrome, no push occurs.

We need the act of raising a window (or creating a new one) to pop everything off the stack before any Web content in the window potentially experiences its `Activate`.
> This is broader than just the Google Japanese IME. Also applies to Microsoft IMEs and not just for Japanese.

Correction: The other IMEs are affected by the steps to reproduce only if the Google IME has been previously active during the lifetime of the Firefox process. Weird. However, with other IMEs, the problem can be reproduced by placing focus in address bar, raising another window and then raising the window whose focus is in the address bar.

So the problem seems to be that the code assumes that newly-created windows initially focuses a `BrowserParent`, which is the case I observed when I was writing the code prior to bug 1549930. (Now I'm curious _why_ I observed that case and not the case seen here.)

The null `BrowserParent`, i.e. browser chrome is never pushed. Getting the stack in the state that represents chrome focus requires pops. The fix for bug 1549930 suppressed pops for `BrowserParent`s in a window being lowered. That fix also accidentally assumes that in the window being raised, focus is in Web content so a push occurs. When the focus is in chrome, no push occurs.

We need the act of raising a window (or creating a new one) to pop everything off the stack before any Web content in the window potentially experiences its `Activate`.

Back to Bug 1562796 Comment 3