1245754 - Explain or correct ActionBar behaviour inconsistencies

Status: RESOLVED DUPLICATE of bug 1246918

(Firefox for Android Graveyard :: Text Selection, defect)

Description

[Mark Capella [:capella]]

Selecting |All| in an <input> then tapping into the middle of the highlighted selection (between the dual AccesibleCarets), will leave the single AccessibleCaret visible, but dismisses the ActionBar.

Was this expected as part of Bug 1240917 - Consider action bar behavior with native text selection ?

Possibly related, I notice that long-pressing an empty <input> will focus the element, and the ActionBar appears. However, the AccesibleCaret does not. Was this part also expected?

Additionally, often, long-pressing a WORD in an <input> seems to properly select the word, and make the AccessibleCarets and ActionBar visible, then quickly hide the AccessibleCarets.

Comment 1

[Ting-Yu Lin [:TYLin] (PDT, UTC-7)]

(In reply to Mark Capella [:capella] from comment #0)
> Selecting |All| in an <input> then tapping into the middle of the
> highlighted selection (between the dual AccesibleCarets), will leave the
> single AccessibleCaret visible, but dismisses the ActionBar.
> 
> Was this expected as part of Bug 1240917 - Consider action bar behavior with
> native text selection ?

Yes. Single tapping does not show actionbar per Bug 1240917 comment 21.

> Possibly related, I notice that long-pressing an empty <input> will focus
> the element, and the ActionBar appears. However, the AccesibleCaret does
> not. Was this part also expected?

Yes. I revert the behavior in bug 1240917 to use original AccessibleCaret behavior that no AccessibleCaret is shown when the input is empty. More details explanation is bug 1240917 comment 20.

> 
> Additionally, often, long-pressing a WORD in an <input> seems to properly
> select the word, and make the AccessibleCarets and ActionBar visible, then
> quickly hide the AccessibleCarets.

I had seen this on some b2g slow devices. If my memory serves, it might be related to APZ that APZ performs the default action before AccessibleCaret handles the event. Can this be easily reproduced on certain website?

Comment 2

[Ting-Yu Lin [:TYLin] (PDT, UTC-7)]

> Possibly related, I notice that long-pressing an empty <input> will focus
> the element, and the ActionBar appears. However, the AccesibleCaret does
> not. Was this part also expected?

Filed bug 1246064 to implement this.

Comment 3

[Mark Capella [:capella]]

With the bugs you filed and corrected, the final outstanding question I had here is the last one:
... then quickly hide the AccessibleCarets ...

I'm easily able to repro launching [0] on my N7 and long pressing the word |production| in the <input>

The good news is I re-tested after applying your patch in bug 1246981 [1] and it seems to correct it! It's a little odd, in that the carets first appear, blink off, then quickly re-appear properly. 

I'd like to dup this over and close this whole bug, unless you think there's something odd remaining that needs to be resolved.


[0] https://www.dropbox.com/s/mzzgw1i4uav925y/test_bug1241558_backspace.html?dl=0
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1246918#c1

Comment 4

[Mark Capella [:capella]]

Sorry, your bug is Bug 1246918 - AccessibleCaret disappears when swiping down the page

Comment 5

[Ting-Yu Lin [:TYLin] (PDT, UTC-7)]

Re comment 3:
It's good to hear the patch in bug1246918 works. Sometimes I saw this behavior on the webpages which allows zooming. After long pressing to select the text, Fennec will automatically zoom the content in which causes carets to hide. After zooming is done, the carets re-appear again.

However I cannot reproduce the caret blink off part on the test case [0] in comment 3. The test case doesn't seem allow zooming. My AccessibleCaret adb log for long pressing the word |production| in the <input> is in https://pastebin.mozilla.org/8859175  I don't see any event which sets caret appearance to not visible. 

If you could help attach the log, I might be able to see the reason behind it :)

To open AccessibleCaret log, you'll need to add a string pref named "logging.AccessibleCaret" (case matters), and set its value to "debug". You don't need to restart the browser or reload the opened page, the log should be seen immediately via "adb logcat".

Finally, I don't see any new bug for now. Please close this bug.

Comment 6

[Mark Capella [:capella]]

Oh, yah, I use Fennec Settings -> Accessibility -> Always enable zoom as True ...

I can see this issue easily [0]

As mentioned, your Bug 1246918 appears to correct this.

[0] https://www.dropbox.com/s/s9r0jecxtg8x2bo/bug_1245754_caretsHide.mp4?dl=0