When scrolling with text selected, the carets lag and don't scroll with with the text as it scrolls; instead the carets "float" on the screen.

Here is a video with the bug: http://youtu.be/eJ_3d8lAqMs

I'm not sure which version of the TextSelection this bug is referring to. While I thought the original reported was referring to the new "GeckoCarets", the recently attached video displays the old "JavaCarets". (fyi all, we've completed a new version of TextSelection handles/carets (bug 988143) and will be rolling it out soon (?) tracking on Bug 1168847. You can test the new version against a nightly build, by enabling both about:config prefs "selectioncaret.enabled" and "touchcaret.enabled".)

Looks like with the new carets on nightly, the problem is fixed.

Leave this one open, I suspect the original reporter is complaining of the way the *new* GeckoCarets behavior differs from the original.

This is for the new carets (the round blue ones) and I still see this problem on a Nightly from around 7/10. It's not the same problem as the video, but rather, the caret stays static relative to the phone edges, even though the text selection can be scrolled.

(In reply to Chenxia Liu [:liuche] from comment #5) > This is for the new carets (the round blue ones) and I still see this > problem on a Nightly from around 7/10. It's not the same problem as the > video, but rather, the caret stays static relative to the phone edges, even > though the text selection can be scrolled. Could you post a screenshot?

Correct, this is a valid separate issue. Note that recent improvements in APZ by kats have this working somewhat more smooth as-is https://www.dropbox.com/s/7vmcbqaw9qn8kfn/bug1166807_scroll.mp4?dl=0 Currently, FF/OS handles this by hiding the carets during scrolling. For the Android version, it's a little more difficult, as the ActionBar visibility is tied to the carets visibility. Basically, if we were to hide the carets during scrolling, the ActionBar would be blinking off then back on in sync. I looked at this before, and I think an enhancement to hide the carets briefly during scrolling without flashing the ActionBar looks possible. We could probably do that in the context of this bug. I've been waiting to do something here, as we'll still have a similar visual issue during Zoom. I thought SelectionCarets.cpp were getting NotifyAsyncPanZoomStarted() and NotifyAsyncPanZoomStopped() triggers like b2g, but that doesn't seem true yet. I forgot to ask kats at Whistler.

Ah, rebuilding with --enable-android-apz does the trick. Looks like we won't get that until APZ goes native for Android.

Yeah, the NotifyAsyncPanZoom* come with the C++ APZ code, which is being worked on in bug 776030 and dependencies but not ready yet. If you want to hook up the caret show/hide behaviour to the Java pan/zoom controller it's a possibility; we'll have to hook in to GeckoLayerClient::scrollBy() (or maybe add a new function there) and GeckoLayerClient::panZoomStopped() to send the notifications to the docshell to make it work.

I have also reproduce this bug on my Firefox nightly mobile 43.0a1 Build ID : 20150811030206 User Agent : Mozilla/5.0 (Android 4.3; Mobile; rv:43.0) Gecko/43.0 Firefox/43.0 STR: 1: Write a wrong web address on my nightly mobile like m.fb.com and it take me to server not found page 2: Try to write correct address on that page search bar and move the cursor among address 3: The cursor showed up right on address and then I can't see the text Here is the picture of the bug https://goo.gl/n2WSIG , https://goo.gl/S9ctFQ

Comment # 11 is a different issue from this report and should be filed new. FYI the issue only seems to involve the old-style carets, and not the newer Gecko Selection carets, so probably won't be prioritized.

Re-testing with new APZ and AccessibleCarets in nightly confirms that: The original issue reported in comment 0 is corrected by design [0]. The issue raised later in comment 11 is also corrected as pictured [1], so we're closing this bug as fixed. [0] https://www.dropbox.com/s/14p2x2r7b9mt2bx/test_bug1160083_scroll.mp4?dl=0 [1] https://www.dropbox.com/s/xmexw30nfi5hqo0/test_bug1166807.png?dl=0