Closed Bug 1258465 Opened 6 years ago Closed 6 years ago
IWeb Browser Focus->activate a Tab Child once it has composited
IME sends sync messages up to the parent process when focus shifts (see bug 1251063). This slows us from painting content when we, for example, first create a browser window or tab, since we'll be blocked on those sync messages for IME. What I propose is that if TabChild gets RecvActivate called on it, it defers the activation until after it has first painted.
Actually, we probably want to wait until the composite has occurred.
Summary: Only nsIWebBrowserFocus->activate a TabChild once it has painted → Only nsIWebBrowserFocus->activate a TabChild once it has composited
So after talking with mstange, I think this might be a bit too ham-fisted. I wanted to defer activation until after paint/composite because of the sync IME messages that come up when the focus is switched to the browser in the new window in tpaint. Those sync messages take a lot of time. What mstange pointed out to me was that if we defer activation, then any messages that are sent down to the content between first receiving the activation and actually _doing_ the activation after the paint, are not going to be interpreted correctly; we're breaking the assumption from the parent that if the content was sent Activate, that it's actually activated. I think what we might want to do instead is figure out if we can somehow defer the IME sync messages coming up from the child instead of the activation message being reacted to by the child.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.