Closed Bug 1121468 Opened 5 years ago Closed 4 years ago

Long-pressing a selection when the selection bubble isn't visible should show the selection bubble

Categories

(Core :: DOM: Selection, defect, P2)

All
Gonk (Firefox OS)
defect

Tracking

()

RESOLVED FIXED
mozilla47
tracking-b2g +
Tracking Status
firefox47 --- fixed

People

(Reporter: cwiiis, Assigned: TYLin)

References

(Blocks 1 open bug)

Details

Attachments

(3 files, 1 obsolete file)

Currently, if you long-press a selection when the selection bubble is missing, the selection bubble will appear while your finger is held down, but releasing your finger will clear the selection and hide the selection bubble accordingly.

If there is an existing selection and the bubble is not visible, long-pressing that selection should not alter the selection, but instead, show the bubble.

This is easily reproduced by going to any URL, tapping in the URL bar and waiting for the URL to appear and the keyboard to come up. Note, the URL will be selected, but there is no selection bubble. Long-pressing the selection exhibits the behaviour described above. Long-pressing again only selects the word, rather than the whole URL, so copying the current URL using this method is a confusing, several-step process.

Nominating to block 2.2, as this bug causes a core feature (copying the URL of a page) to be very confusing and convoluted.
ni UX about the URL selection behavior.
Flags: needinfo?(ofeng)
Priority: -- → P2
BTW I also find similar behavior from the iOS but they do provide less steps to select whole URL than FxOS.
To make it simple and consistent, IMO, the touch carets and utility bubble should always be visible when some text is selected, no matter the selection is triggered by user or by code. (BTW, scrolling or zooming still hide the touch carets and utility bubble temporarily, but that's another story.)
Flags: needinfo?(ofeng)
Triage: Not a blocker but not so user friendly. Put as priority bug and George will take a look first.
Assignee: nobody → gduan
blocking-b2g: 2.2? → backlog
tracking-b2g: --- → +
Since the caret would disappear when js try to manipulate its position or selection area, I would suggest to use contenteditable div to replace input.
blocking-b2g: backlog → ---
There 're two solutions for this bug
1. fix in Gecko: as what comment 3 stated, all kinds of selection should be with bubble no matter it's from user action or js. 
2. fix in browser: as what comment 5 stated, replace input tag with contenteditable div, that could be a workaround for this bug. but we might not be able to scroll to div's end from code based on original ux behavior.
Assignee: gduan → nobody
Ideally, we should show caret and copy & paste menu whenever selection is visible on the screen. However, it's very difficult to tell whether a selection is really visible on the screen since it might be on a lower level layer.

So I would like to ask UX to reconsider the proposal in the description. 

"If there is an existing selection and the bubble is not visible, long-pressing that selection should not alter the selection, but instead, show the bubble."

To reiterate, we should show carets and bubble again if the user is long-pressing on the visible selection "without" any carets, and the selection range remains unchanged. If a selection already had carets and bubble. The behavior is the same as before. That is, it still selects a word. Does this make sense?
NI for comment #8.
Flags: needinfo?(tchen)
> To reiterate, we should show carets and bubble again if the user is
> long-pressing on the visible selection "without" any carets, and the
> selection range remains unchanged. If a selection already had carets and
> bubble. The behavior is the same as before. That is, it still selects a
> word. Does this make sense?

If it is not feasible to show caret and utility bubble whenever text is selected, this proposal seems fine to UX. We should show carets and utility bubble when users long press on the selected area without carets.
Flags: needinfo?(tchen)
Tori, thank you for your feedback.
Assignee: nobody → tlin
Status: NEW → ASSIGNED
Both 'auto' and 'auto*' do not change the type inference. However, auto*
make 'self' only accept a pointer which is our intent here.

Review commit: https://reviewboard.mozilla.org/r/32233/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/32233/
Attachment #8711600 - Flags: review?(roc)
The blur event will hide the carets and produces a standalone selection
highlight without carets. When a user long-pressing on the highlight, we
should show carets for the original selection highlight instead of
select a new word.

The helper UpdateCaretsWithHapticFeedback() should only be needed when
long-pressing. It should suffice to live within SelectWordOrShortcut()
instead of being a member function.

Review commit: https://reviewboard.mozilla.org/r/32235/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/32235/
Attachment #8711601 - Flags: review?(roc)
Comment on attachment 8711600 [details]
MozReview Request: Bug 1121468 - Use auto* to explicit declare 'self' as a pointer. r?roc

https://reviewboard.mozilla.org/r/32233/#review29213
Comment on attachment 8711601 [details]
MozReview Request: Bug 1121468 - Show carets when long-pressing on selection highlight. r?roc

https://reviewboard.mozilla.org/r/32235/#review29215
Comment on attachment 8711602 [details]
MozReview Request: Bug 1121468 - Go to NoActionState after receiving release on LongTapState. r?roc

https://reviewboard.mozilla.org/r/32237/#review29217
Attachment #8711602 - Flags: review?(roc) → review+
https://hg.mozilla.org/mozilla-central/rev/0624437c04f6
https://hg.mozilla.org/mozilla-central/rev/4d4a61e9c257
https://hg.mozilla.org/mozilla-central/rev/0049e7998c1a
Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla47
No longer blocks: 1246477
Depends on: 1246477
You need to log in before you can comment on or make changes to this bug.