As part of turning on APZ in the B2G root process, I plan to fix the fact that we dispatch mouse events for every touch. Instead, the root process should only expect to receive a single touchmove,touchdown,touchup,click sequence every time the user taps on something in the root process. Currently this breaks various things in Gaia because I believe there are bits of code here and there that are relying on the current mouse event behaviour. This meta bug covers the changes needed here. To provide a concrete example that I've run across already is when you tap in the rocketbar from the homescreen to do a search, the keyboard comes up. If you then enter some text and tap in the results area, the keyboard dismisses. This keyboard dismissal appears to be triggered by mouse events (not sure yet exactly where the listener for this is yet), and this behaviour breaks when we stop delivering mouse events.

(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #0) > To provide a concrete example that I've run across already is when you tap > in the rocketbar from the homescreen to do a search, the keyboard comes up. > If you then enter some text and tap in the results area, the keyboard > dismisses. This keyboard dismissal appears to be triggered by mouse events > (not sure yet exactly where the listener for this is yet), and this > behaviour breaks when we stop delivering mouse events. Further investigation seems to indicate that this is actually a result of the search field only blurring in response to mouse events, rather than touch events. This might just be expected behaviour, given that the user can explicitly hide the keyboard by long-pressing the spacebar.

I haven't run into anything else so far that is actually a problem on this front. All the issues I was running into turned out to be other stuff. Closing this bug for now but might reopen it later.

(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #1) > Further investigation seems to indicate that this is actually a result of > the search field only blurring in response to mouse events, rather than > touch events. This might just be expected behaviour, given that the user can > explicitly hide the keyboard by long-pressing the spacebar. Just to be a bit more clear on this point: in all other parts of B2G (e.g. settings app, browser, whatever) it is possible to scroll content while the keyboard is visible. The attempt to scroll the content doesn't automatically dismiss the keyboard. This only happens in the root process (i.e. rocketbar) because of the spurious mouse events that the platform is sending it. These spurious mouse events will be removed in bug 1005815 and will make the behaviour in the root process consistent with the behaviour in other processes.