Fennec nightly on Android 4.2.2 on a Nexus 4. When tapping into a input field with autocomplete history the autocomplete popup lags behind the scroll position quite a bit, and sometimes doesn't catch up at all. In the given screenshot, I tapped in the whiteboard field. The browser showed the autocomplete popup (which was properly aligned) and then also did a "zoom to input" which zoomed the content view but didn't reposition the autocomplete panel. As a result it looks "disconnected" and remains this way until I do something like scrolling that forces it to update again. Even while scrolling the autocomplete panel lags behind the scroll position and generally behaves less well than expected. We should just hide the panel while the user is actively scrolling if we can't keep it in sync.

My initial investigation indicates with APZ, the end touch event is what causes the panel to re-position. Things like flings and panning an input field into view do not currently affect its position. In JPZ the panel is only visible when the field is not being scrolled.

The issue seems to be that APZ does not send the PanZoom:StateChange event that JPZ does which is used by the FormAssistPopup to properly determine visibility.

Comment on attachment 8742574 [details] [diff] [review] 0001-Bug-1265551-Autocomplete-popup-lags-behind-pan-zoom-position-16041817-2df14f1.patch Review of attachment 8742574 [details] [diff] [review]: ----------------------------------------------------------------- Eventually I'd like to avoid having to go through the main thread for this, since it's going to be a bit laggy. We should be able to route this message to Java directly and hide the popup there, but I think that's going to be a bigger change since there's layers of abstraction to punch through. This is good for now.

(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #4) > Comment on attachment 8742574 [details] [diff] [review] > 0001-Bug-1265551-Autocomplete-popup-lags-behind-pan-zoom-position-16041817- > 2df14f1.patch > > Review of attachment 8742574 [details] [diff] [review]: > ----------------------------------------------------------------- > > Eventually I'd like to avoid having to go through the main thread for this, > since it's going to be a bit laggy. We should be able to route this message > to Java directly and hide the popup there, but I think that's going to be a > bigger change since there's layers of abstraction to punch through. This is > good for now. I agree that this would be better if it was simpler but I don't think it will add any latency compared to JPZ since for JPZ it goes: UI Thread (Java) -> Main Thread (browser.js) -> UI Thread (Java) while APZ now goes Compositor -> Main Thread (browser.js) -> UI Thread (Java). So it is two thread hops for both. I'll create a follow up bug for simplifying how this works.

Verified as fixed in Firefox 48.0a2 (2016-05-23) on Motorola Nexus 6 (Android 6.0)