1536419 - Consider capturing the focused TabParent in nsIPresShell::PushCurrentEventInfo()

Status: NEW

(Core :: DOM: UI Events & Focus Handling, enhancement, P3)

Description

[Henri Sivonen (:hsivonen)]

From https://phabricator.services.mozilla.com/D20981 :

Masayuki Nakono wrote:

Although out of scope of this bug, eventTarget should be have a TabParent and the result of TabParent::GetFocused() should be it or for one of its out-of-process iframes. So, perhaps, mPresShell should have mCurrentEventTabParent for guaranteeing the relation.

Henri Sivonen wrote:

What object's mPresShell you are referring to? I don't understand which object should gain mCurrentEventTabParent. That is, I don't understand what other object in addition to TextComposition should record which TabParent was focused at this point.

Masayuki Nakono wrote:

I meant that PresShell::EventHandler's mPresShell. I think that when nsIPresShell::PushCurrentEventInfo() is called or mCurrentEventContent and/or mCurrentEventFrame is directly modified, proper TabParent should be recorded. Note that event dispatching may be nested, but I'm still not so familiar with which cases there are though.

One possible scenario is, user types something with IME in a content process, but that causes a nested event dispatch and that may cause changing focused TabParent. Then, the composition string might be leaked into new TabParent's process. But anyway, I'm talking about edge cases.

Comment 1

[Henri Sivonen (:hsivonen)]

I don't know this code well enough to understand the edge cases. Masayuki, what action, if any, should we take here?

Comment 2

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

I think that we should fix this or changes current design around it, anyway, the data should be synced in any cases. However, I don't think that this is important to fix before the first Fission release.