Closed Bug 1249490 Opened 8 years ago Closed 8 years ago

Long-pressing to paste always selects text

Categories

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

ARM
Android
defect
Not set
normal

Tracking

(firefox47 affected, fennec47+)

RESOLVED DUPLICATE of bug 1252552
Tracking Status
firefox47 --- affected
fennec 47+ ---

People

(Reporter: liuche, Unassigned)

Details

Long-press to bring up the paste menu. Text is selected, and it's not possible to unselect the text by tapping on blank space, or moving the text handles. I don't think this used to be the case (but I could be wrong).
I just checked with a fresh build, and this seems to be working to my current understanding. I can un-select by tapping at different locations in the <input> element, either within the initially selected span, or to either side of it.

This should collapse the selection to a single (AccessibleCaret), and close the ActionBar allowing cursor positioning. You can re-open the ActionBar by tapping on the AccessibleCaret.

I think this is a dup of Bug 1235666 comment 8 ... basically we've been changing TextSelection and ActionBar behaviour to be more like native Android.

For background discussions, see:
Bug 1240917 - Consider action bar behavior with native text selection
Bug 1246487 - Support single tap on the caret to show actionbar when selection is collapsed.
Status: NEW → UNCONFIRMED
Ever confirmed: false
Flags: needinfo?(liuche)
Oh, I see what you mean - I was not aware that I needed to tap on the single caret to activate paste, and expected that I could either move the carets to unselect everything, or tap on the blank area to perhaps clear the selection but keep the action bar up. fwiw, this seems completely unobvious, and I've never encountered any other UI that has that.

Why require the carets to always select text? Would it be possible to slide them together and turn that into the single caret? (This might be annoying, or beyond the scope.) This would certainly make it seem more discoverable.

I would consider morphing this bug into making the UX more clear, but I understand that's not an easy thing to ask for :P Otherwise, feel free to close this bug.

(I'm also seeing an unrelated bug where the cursor + single text handle are still present and flashing, even when the keyboard is hidden and text input is not possible in the current state.)
Flags: needinfo?(liuche)
Odd you've not noticed ... the "single tap to open the ActionBar/Utility Bubble" behaviour is patterned off Chrome [0].

I'm not sure what you're asking regarding "Why require the carets to always select text" ... can you elaborate?

Regarding "sliding the carets together to combine them", I'd love that! I actually had a patch for the old style carets that did that. 

I'm cc:ing antlam, as he's driving the UI design here and can better comment on overall flow, etc.

Regarding the bug "... where the cursor + single text handle are still present and flashing, even when the keyboard is hidden and text input is not possible in the current state" ... I've not noticed that. Can you file a new bug with STR ?


[0] https://www.dropbox.com/s/8rcu4o9b5i5rgp3/bug_1240917_tap_Chrome.mp4?dl=0
(In reply to Chenxia Liu [:liuche] from comment #0)
> Long-press to bring up the paste menu. Text is selected, and it's not
> possible to unselect the text by tapping on blank space, or moving the text
> handles. I don't think this used to be the case (but I could be wrong).

I see this on some sites too. Where, I can't press outside the selection to get the single caret all the way at the end (thereby un-selecting the text already in the input field). 

This sounds like a bug. Maybe kbrosnan has seen this?

WRT the past menu, I think bug 1171110 could help this UX issue.
Flags: needinfo?(kbrosnan)
tracking-fennec: --- → ?
I think this is the same thing I'm complaining about it in bug 1252552
tracking-fennec: ? → 47+
Status: UNCONFIRMED → RESOLVED
Closed: 8 years ago
Flags: needinfo?(kbrosnan)
Resolution: --- → DUPLICATE
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in before you can comment on or make changes to this bug.