Here's a profile for one of our talos machines running tpaint: http://people.mozilla.org/~bgirard/cleopatra/?zippedProfile=http://mozilla-releng-blobs.s3.amazonaws.com/blobs/Try/sha512/55a971fe381852c780710a52119165fa0f64ed4fc2fba1070918c343ba34cbe2eccd3937a153ebef1d0e9dda89def9f3c60d4cbf391297a28ffc0124f9856156#report=f766568ca6a67eb36396a1139181f8ad05090aef&filter=%5B%7B%22type%22%3A%22RangeSampleFilter%22,%22start%22%3A19548,%22end%22%3A20191%7D,%7B%22type%22%3A%22RangeSampleFilter%22,%22start%22%3A19609,%22end%22%3A19956%7D%5D&selection=0,8293,6,7,8294,8295,4,5,6,7,8294,8,9,10,11,12,13,14,15,16,17,8335,8339,8340,8341,8342,1532,1744,2654,2655 There is a sync message going to the parent at 19886 to 19930 - it's the GetInputContext sync message, and it's coming up from the IMEStateManager in response to an Activate message being sent from the parent (we're focusing the new remote browser in the new window). That sync message is occurring before the content has had a chance to paint or composite, so it's slowing down presentation to the user. Is it possible to defer these sync messages (since there are two - see bug 1251063) until after painting and composing the content are complete?

Hello :masayuki! Do you have a sense of how practical it would be to defer these IME sync messages until after content has been presented to the user?

> Is it possible to defer these sync messages (since there are two - see bug 1251063) until after > painting and composing the content are complete? I think that it's impossible because async paint isn't matter for users to input text or keyboard navigation. There are two scenarios: 1. Current state is "enabled" but new state is "disabled". In this case, IME should be disabled as soon as possible because user might type something during load even without focus in editor. Then, IME handles the key events, this may cause composition events but no body will handle this correctly. This will cause making IME confused because modern IME API works with queried contents information. 2. Current state is "disabled" but new state is "enabled". In this case, if user knows focus is automatically set to an input element like search engine's home, the user may start to type some character before painting especially when the process is really slow due to busy. Then, user expects the key events cause composition string, but instead, text is directly inputted into the <input> element. So, putting off managing IME state from focus change causes a lot of issue and which are not assumed by a lot of code. So, if you *really* need the delay, focus change shouldn't occur until the first paint.

Oh, I realized that GetInputContext() is mainly used for optimization avoiding unnecessary reinitialization in non-e10s mode. So, it might be able to remove the optimization, but I need to investigate more.

Mike, are you working on this?

I think masayuki is - although, if I'm able to get bug 1262946 reviewed and landed, this work might not be necessary.