software keyboard is very slow and randomly jumps around when typing.

need a little more detail. What is slow? and what do you mean by jumps around?

sorry for the brevity, but it was painful to type on my phone. Busted out the laptop now. Basically there is a one to two second delay between each keypress, and randomly my cursor would shift to somewhere that I already typed. Since I was so far ahead of the UI in terms of what I typed, I'd have a good chunk of what I typed in the middle of existing text.

I should also note that this is only when the keyboard is for something in the content process. Chrome process is fine.

in bug 591047 comment 48 roc asked jim to drop some optimizations designed to decrease the communication across the chrome/content boarder. I'm curious if adding those back in makes this any better.

I see this with the hardware keyboard too

Those optimizations did not decrease the number of messages, just the length of the strings involved. If the software keyboard is slow even when, say, typing a single character into an empty textarea, then they won't help here.

Right, what roc said. I suspect it has something to do with cross-process layers. Editor code does synchronous painting when entering text, so a slow-down in layers would directly affect perceived responsiveness. Bug 596542 was one bug that made keyboard interaction very slow before it was fixed. This bug might be something similar.

(In reply to comment #7) > Editor code does synchronous painting when entering text, so a slow-down in > layers would directly affect perceived responsiveness. I'll note that when I'm typing with the software keyboard in landscape mode, none of the browser is even showing, and the textbox that shows what is being typed in, as far as I can tell, is done by android.

(In reply to comment #8) > (In reply to comment #7) > > Editor code does synchronous painting when entering text, so a slow-down in > > layers would directly affect perceived responsiveness. > I'll note that when I'm typing with the software keyboard in landscape mode, > none of the browser is even showing, and the textbox that shows what is being > typed in, as far as I can tell, is done by android. Right, Android displays an overlay on top of the browser in landscape mode. But at the same time, all keystrokes and IME events still go through Gecko, which triggers painting. Here's a build that turns on async updates in text fields (using the above patch); should feel a lot more responsive: http://ftp.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/jimnchen@gmail.com-0c65746ad523/tryserver-android-r7/

Bug 174823 will do this for all text fields.

FWIW, I'm seeing this pretty frequently in the logs WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0x80040111: file /home/cjones/mozilla/mozilla-central/content/events/src/nsContentEventHandler.cpp, line 127 which is nsresult rv = InitCommon(); NS_ENSURE_SUCCESS(rv, rv); Doesn't look very good to me.

Here's an IPC log I gathered on fennec/desktop for Ctrl-Shift-u + 1 + [spacebar]. My annotations are indented. Jim, does the IME stuff here look like you would expect? [time:1285620602814838][PBrowserParent] Sending Msg_AsyncMessage([TODO]) Ctrl? [time:1285620602906102][PBrowserParent] Sending Msg_AsyncMessage([TODO]) Shift? [time:1285620603082882][PBrowserParent] Sending Msg_AsyncMessage([TODO]) u? [time:1285620603083225][PBrowserParent] Sending Msg_CompositionEvent([TODO]) [time:1285620603087258][PBrowserParent] Sending Msg_TextEvent([TODO]) [time:1285620603120602][PLayersChild] Sending Msg_Update([TODO]) Paint underlined u. [time:1285620603142014][PLayersChild] Sending Msg_Update([TODO]) Paint moved caret? [time:1285620603433985][PBrowserParent] Sending Msg_TextEvent([TODO]) [time:1285620603466432][PLayersChild] Sending Msg_Update([TODO]) [time:1285620603485918][PLayersChild] Sending Msg_Update([TODO]) ??? [time:1285620603625990][PBrowserParent] Sending Msg_TextEvent([TODO]) [time:1285620603626705][PBrowserParent] Sending Msg_CompositionEvent([TODO]) [time:1285620603630193][PBrowserParent] Sending Msg_AsyncMessage([TODO]) [time:1285620603630409][PBrowserParent] Sending Msg_CompositionEvent([TODO]) [time:1285620603633159][PBrowserParent] Sending Msg_TextEvent([TODO]) [time:1285620603635397][PBrowserParent] Sending Msg_CompositionEvent([TODO]) [time:1285620603650812][PLayersChild] Sending Msg_Update([TODO]) [time:1285620603673243][PLayersChild] Sending Msg_Update([TODO]) Maybe painting 'u\0x1' and moving cursor. [time:1285620603696630][PLayersChild] Sending Msg_Update([TODO]) ??? [time:1285620603706309][PBrowserParent] Sending Msg_AsyncMessage([TODO]) [time:1285620603710164][PBrowserChild] Sending Msg_AsyncMessage([TODO]) [time:1285620603711101][PBrowserChild] Sending Msg_AsyncMessage([TODO])

(In reply to comment #11) > FWIW, I'm seeing this pretty frequently in the logs > > WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0x80040111: file > /home/cjones/mozilla/mozilla-central/content/events/src/nsContentEventHandler.cpp, > line 127 > > which is > > nsresult rv = InitCommon(); > NS_ENSURE_SUCCESS(rv, rv); > > Doesn't look very good to me. That means you ran into an event we don't forward to content yet :) Should only happen on desktop. Those events mostly deal with screen coordinates, etc., and are not used on Android or Maemo. (In reply to comment #12) > Here's an IPC log I gathered on fennec/desktop for Ctrl-Shift-u + 1 + > [spacebar]. My annotations are indented. > > Jim, does the IME stuff here look like you would expect? > Looks OK. I guess it really depends on which IME, but yeah composition events should come in pairs, and text events should be inside each pair.

(In reply to comment #9) > Here's a build that turns on async updates in text fields (using the above > patch); should feel a lot more responsive: > http://ftp.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/jimnchen@gmail.com-0c65746ad523/tryserver-android-r7/ So this build is a bit better, but it's still not great. At roughly the pause interval before for each key I typed I get a bunch of them, but there is still that pause every so often.

I've been looking into this for a while, but there are several things to disentangle. Posting prematurely with what I have so far. This bug is rather poor in that no one has posted a URL or STR. A build that should be equivalent to the latest nightly works just fine on http://people.mozilla.com/~cjones/input.html . It's hard to tell the difference between the character-paint lag on that page and the lag typing into the fennec UI. So it's not our painting or IME code per se. One site where bad behavior can be observed is on http://www.google.com (instant version). If I type at a very high rate, as auto-complete results start coming in, there are noticeable lags between character paints. I noticed while testing on desktop that we send several pref requests for each input event handled in content, so I suspected prefs were causing us to get backed up. I applied Doug's prefs patch and things appeared to get better ... however, it's hard for me to confirm because I'm running into what I believe is bug 599810, both with and without the pref patch. That bug seems to be related to IME. With sites that autocomplete from input events, we're always vulnerable to issues similar to this because web content can block input-event handling. (Try http://netflix.com in mobilesafari.)

(In reply to comment #15) > This bug is rather poor in that no one has posted a URL or STR. A build that > should be equivalent to the latest nightly works just fine on I filed this bug because it was slow filing bugs in bugzilla. the enter_bug.cgi page was what I was using as a test area.

Thanks Shawn. I am seeing more of a lag on http://people.mozilla.com/~cjones/input-large.html than I am on http://people.mozilla.com/~cjones/input.html, which leads me to believe the lag is proportional to page size. Certainly shouldn't be, since we have to repaint the same size region when a new character is entered regardless of page size. (There's a known inefficiency in the invalidation of the <browser>'s frame on content-process updates on the chrome side, but since scrolling perf is very fast I don't think that invalidate is slowing us down.) Poking some more.

There's a fair amount of goop in this patch, but the core of it is the description of the patch. This makes various test cases noticeably faster, google.com and enter_bug.cgi among them. Unfortunately, it's also fairly easy to expose the fundamental issue with the swap-and-invalidate synchronization approach: the region we repaint in the new back buffer after swaps accumulates the repainted regions. So if an input field is focused and the user pans around, we have to keep repainting the union of all invalidated regions. I think this should be enough for b1; to really fix this issue with SW compositing, we'll need bug 598866, but for b2, we'll have HW compositing and probably won't need that fix (since we'll likely only have one surface in system memory). I'd like to defer that discussion if perf with these patches and the prefs fix is acceptable.

Bug 174823 could also help in that it could reduce the number of repaints the content process does, but I'm not able to assess its risk.

There are ways to make key input be slow even with these patches, but let's open new bugs for new work. http://hg.mozilla.org/mozilla-central/rev/9c47254208d0 http://hg.mozilla.org/mozilla-central/rev/6a5d2399012c

Just FTR, this was also a problem on the n900 with the HW keyboard.