Bugzilla

(In reply to Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(Might be slow response)(away 5/10~5/19) from comment #8)

> No, we shouldn't need such checks. We should handle input events even on inactive windows with active element in active document in it.

This surprises me, considering that a window becoming inactive means that IME composition gets committed. If inactive windows are expected to have normal IME compositions, how does `TextComposition` get created in this case?

> > Can we make Widget trigger caching of the focused `BrowserParent` (including `nullptr` if chrome is focused) when Firefox as a whole is about to lose focus? What would be the right place in the Widget code to do stuff before letting Firefox as a whole lose focus before actually triggeting the focus deactivation?
> 
> Currently, [`BrowserParent::PopFocus()` makes itself forget focus information](https://searchfox.org/mozilla-central/rev/197210b8c139b64f642edaa3336d26b9c1761568/dom/ipc/BrowserParent.cpp#2707-2732) when [`BrowserParent::Deactivate()` is called](https://searchfox.org/mozilla-central/rev/197210b8c139b64f642edaa3336d26b9c1761568/dom/ipc/BrowserParent.cpp#1107,1109). From a point of view of user input event handling, this must be wrong. Any 3rd party applications (including IME and a11y tools) can synthesize input events even on inactive window (i.e., on inactive `nsIWidget` instance). So, if we can keep `sFocusStack` even during inactive, this must be able to fix easy. Can we do that?

The code I added for Fission IME handling is based on the assumption that inactive windows cannot receive keyboard events or perform IME compositions.

`Activate`/`Deactive` calls don't carry information on whether focus is moving or the whole native window is going to the background, so we can't simply keep the stack.

> Or we need to move the information into another one?

We could take a snapshot of the top of the focus stack before the stack changes if we act from a widget signal before actually performing the `Deactivate` calls, but...

> Note that if web content moves focus with `Element.focus()` on inactive window, the target should be changed to new active element. So, I think that `BrowserParent` needs to keep managing focused `TabParent` even while it's inactive.

...just taking a snapshot wouldn't handle the case of Web content moving focus in an inactive window. I don't have any obvious ideas of how the case of focus moving in an inactive window between processes could be handled. Do you have a suggestion? How bad would it be if we didn't handle that case?

(In reply to Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(Might be slow response)(away 5/10~5/19) from comment #8)

> No, we shouldn't need such checks. We should handle input events even on inactive windows with active element in active document in it.

This surprises me, considering that a window becoming inactive means that IME composition gets committed. If inactive windows are expected not to have normal IME compositions, how does `TextComposition` get created in this case?

> > Can we make Widget trigger caching of the focused `BrowserParent` (including `nullptr` if chrome is focused) when Firefox as a whole is about to lose focus? What would be the right place in the Widget code to do stuff before letting Firefox as a whole lose focus before actually triggeting the focus deactivation?
> 
> Currently, [`BrowserParent::PopFocus()` makes itself forget focus information](https://searchfox.org/mozilla-central/rev/197210b8c139b64f642edaa3336d26b9c1761568/dom/ipc/BrowserParent.cpp#2707-2732) when [`BrowserParent::Deactivate()` is called](https://searchfox.org/mozilla-central/rev/197210b8c139b64f642edaa3336d26b9c1761568/dom/ipc/BrowserParent.cpp#1107,1109). From a point of view of user input event handling, this must be wrong. Any 3rd party applications (including IME and a11y tools) can synthesize input events even on inactive window (i.e., on inactive `nsIWidget` instance). So, if we can keep `sFocusStack` even during inactive, this must be able to fix easy. Can we do that?

The code I added for Fission IME handling is based on the assumption that inactive windows cannot receive keyboard events or perform IME compositions.

`Activate`/`Deactive` calls don't carry information on whether focus is moving or the whole native window is going to the background, so we can't simply keep the stack.

> Or we need to move the information into another one?

We could take a snapshot of the top of the focus stack before the stack changes if we act from a widget signal before actually performing the `Deactivate` calls, but...

> Note that if web content moves focus with `Element.focus()` on inactive window, the target should be changed to new active element. So, I think that `BrowserParent` needs to keep managing focused `TabParent` even while it's inactive.

...just taking a snapshot wouldn't handle the case of Web content moving focus in an inactive window. I don't have any obvious ideas of how the case of focus moving in an inactive window between processes could be handled. Do you have a suggestion? How bad would it be if we didn't handle that case?