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.

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.)

Triage: Not a blocker but not so user friendly. Put as priority bug and George will take a look first.

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.

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.

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.

> 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.

Tori, thank you for your feedback.

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/

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/

This makes the state change match the user action. No functionality changes is expected. Review commit: https://reviewboard.mozilla.org/r/32237/diff/#index_header See other reviews: https://reviewboard.mozilla.org/r/32237/

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

https://hg.mozilla.org/integration/mozilla-inbound/rev/0624437c04f6 https://hg.mozilla.org/integration/mozilla-inbound/rev/4d4a61e9c257 https://hg.mozilla.org/integration/mozilla-inbound/rev/0049e7998c1a

https://hg.mozilla.org/mozilla-central/rev/0624437c04f6 https://hg.mozilla.org/mozilla-central/rev/4d4a61e9c257 https://hg.mozilla.org/mozilla-central/rev/0049e7998c1a

https://hg.mozilla.org/mozilla-central/rev/0624437c04f6 https://hg.mozilla.org/mozilla-central/rev/4d4a61e9c257 https://hg.mozilla.org/mozilla-central/rev/0049e7998c1a