1246487 - Support single tap on the caret to show actionbar when selection is collapsed

Status: RESOLVED FIXED

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

Description

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

After bug 1240917 resolved, the actionbar does not show after single tapping on an filled input. (See bug 1240917 comment 15). So if the user want to paste some text from the clipboard after dragging the single caret, we need to find a way to show the actionbar. Otherwise issues like bug 1018784 might be filed again.

Some discussion happen in bug 1240917 comment 16 and bug 1240917 comment 17. 

What I propose is that we follow the behavior of B2G and Google Chrome, we can single tap on the caret to show the actionbar. Any other ideas?

Comment 1

[Mark Capella [:capella]]

This probability was pointed out somewhat earlier in the discussion at bug 1240917 comment 7, and bug 1240917 comment 8.

I'd like to think we're noticing and considering points as they're being raised, rather than rushing into changes that lead to unintended consequences.

Now, 1) I dropped out of the discussion after that, and 2) we're mostly only impacting fellow devs in m-c (vs. actual end-users) as this is a guarded experimental set of changes, so I can't really push on "I told you so".

I'm trying to gently point out that we're looking to target this to v48 (last I checked), and having to fallback and fold fixes in after the fact complicates debugging and migration planning.

Comment 2

[:Margaret Leibovic]

(In reply to Mark Capella [:capella] from comment #1)
> This probability was pointed out somewhat earlier in the discussion at bug
> 1240917 comment 7, and bug 1240917 comment 8.
> 
> I'd like to think we're noticing and considering points as they're being
> raised, rather than rushing into changes that lead to unintended
> consequences.
> 
> Now, 1) I dropped out of the discussion after that, and 2) we're mostly only
> impacting fellow devs in m-c (vs. actual end-users) as this is a guarded
> experimental set of changes, so I can't really push on "I told you so".
> 
> I'm trying to gently point out that we're looking to target this to v48
> (last I checked), and having to fallback and fold fixes in after the fact
> complicates debugging and migration planning.

We'd like to ship APZ and the native carets in 47, so we should focus on resolving any outstanding issues here.

I haven't followed this UX discussion closely, but these new carets are going to be the default for all users, so we should not think of this as an "experimental" feature. This needs to be ready to ship to all users.

Comment 3

[Mark Capella [:capella]]

Oh! Thank you, I'd referred to the "Feature Board" [0] ... it must be outdated. To be clear, I can't imagine us not wanting this functionality, and as TYLin has volunteered, it's trivial [1] and allows feature parity with Chrome [2] vs. [3].

[0] https://mozilla.aha.io/published/9e4032368f0ba842dbc2f121a8246b36?page=2
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1240917#c18

[2] https://www.dropbox.com/s/8rcu4o9b5i5rgp3/bug_1240917_tap_Chrome.mp4?dl=0
[3] https://www.dropbox.com/s/exjnedayk5yhemn/bug_1240917_tap_Fennec.mp4?dl=0

Comment 4

[Anthony Lam (:antlam) Find me, @antlam on Slack!]

(In reply to Ting-Yu Lin [:TYLin] (UTC+8) (Chinese New Year 2/6 - 2/14, slow response) from comment #0)
> After bug 1240917 resolved, the actionbar does not show after single tapping
> on an filled input. (See bug 1240917 comment 15). So if the user want to
> paste some text from the clipboard after dragging the single caret, we need
> to find a way to show the actionbar. Otherwise issues like bug 1018784 might
> be filed again.
> 
> Some discussion happen in bug 1240917 comment 16 and bug 1240917 comment 17. 
> 
> What I propose is that we follow the behavior of B2G and Google Chrome, we
> can single tap on the caret to show the actionbar. Any other ideas?

I don't think we should do this. I don't think single tapping on an input field (filled or not) to show an action bar is good UX. The primary use case for single tapping is to type. Not to copy, or paste, or what not - that's for long-press.

Considering that there's also auto filled form items that drop down from single-tapping on an input field, I don't think we should be complicating our users' single tap action any further. 

I also don't see this behaviour on my Chrome on any of my devices (testing on Chrome on N5, and 6P, both 6+)

Comment 5

[Mark Capella [:capella]]

Still trying to clarify. we're suggesting that similar to Chrome viewable above and here [0], if you tap on the single visible AccessibleCaret (versus into an <input> text field), you open the ActionBar and provide the use of options like paste-at-cursor and select-all, allowing common actions following cursor positioning.

Chrome currently does this, Fennec does not. For demonstration purposes, the link at [1] is Fennec with the patch applied, and is meant to show how our behaviour would match and look.

Quick note, once FloatingToolbar is available, we'd of course pop-up the bubble instead.

I'm sorry if advance if I'm doing something wrong, I'm not sure how you can't repro this in Chrome. I recorded that on my N7 with 6.0.1.

[0] https://www.dropbox.com/s/8rcu4o9b5i5rgp3/bug_1240917_tap_Chrome.mp4?dl=0
[1] https://www.dropbox.com/s/exjnedayk5yhemn/bug_1240917_tap_Fennec.mp4?dl=0

Comment 6

[:Margaret Leibovic]

Anthony, can you help us figure out what we need to do here? I leave it to you to decide if this is a WONTFIX.

Comment 7

[Anthony Lam (:antlam) Find me, @antlam on Slack!]

(In reply to Mark Capella [:capella] from comment #5)
> Still trying to clarify. we're suggesting that similar to Chrome viewable
> above and here [0], if you tap on the single visible AccessibleCaret (versus
> into an <input> text field), you open the ActionBar and provide the use of
> options like paste-at-cursor and select-all, allowing common actions
> following cursor positioning.
> 
> Chrome currently does this, Fennec does not. For demonstration purposes, the
> link at [1] is Fennec with the patch applied, and is meant to show how our
> behaviour would match and look.
> 
> Quick note, once FloatingToolbar is available, we'd of course pop-up the
> bubble instead.
> 
> I'm sorry if advance if I'm doing something wrong, I'm not sure how you
> can't repro this in Chrome. I recorded that on my N7 with 6.0.1.
> 
> [0] https://www.dropbox.com/s/8rcu4o9b5i5rgp3/bug_1240917_tap_Chrome.mp4?dl=0
> [1] https://www.dropbox.com/s/exjnedayk5yhemn/bug_1240917_tap_Fennec.mp4?dl=0

Thanks for the videos Capella.

Let's go ahead and do this - I'm ok with this UX of pressing the caret to trigger the action bar right now.

Comment 8

[Mark Capella [:capella]]

Oh awesome! I find this is a useful bit of UI, so thank-you for including it in the product. As TYLin laid the path for this, I assume he'd like to provide / complete the patch. I'll help if he's busy with the others bits like the carets redesign, etc.  :-)

Comment 9

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

I can do this :)

Comment 10

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

Attachment: MozReview Request: Bug 1246487 - Support single tap on the caret to show actionbar. r=capella

Review commit: https://reviewboard.mozilla.org/r/34961/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/34961/

Comment 11

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

Attachment: MozReview Request: Bug 1246487 - Remove TouchCaret/SelectionCarets from comments in ActionBarHandler.js. r=capella

Review commit: https://reviewboard.mozilla.org/r/34963/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/34963/

Comment 12

[Pulsebot]

https://hg.mozilla.org/integration/fx-team/rev/e10dae6932b5
https://hg.mozilla.org/integration/fx-team/rev/288bdc6d7788

Comment 13

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/e10dae6932b5
https://hg.mozilla.org/mozilla-central/rev/288bdc6d7788

Comment 14

[Teodora Vermesan (:TeoVermesan)]

Tapping on the single caret within a filled input will display the action bar, so:
Verified as fixed using:
Device: One A2001 (Android 5.1.1) 
Build: Firefox for Android 47.0a1 (2016-02-18)