As a user, I want to be able to select text easily in order to perform actions on the selection (insert/delete/copy/cut, etc)

Update whiteboard tag to follow format [ucid:{id}, {release}:p{1,2}, ft:{team-id}]

This user story will track text selection for editable text fields.

Need info Carrie to ask the UX spec. for text selection.

The spec is same as the one attached in Bug 921964. It includes both cursor movement and the text selection. Thanks!

Move this feature to v1.5.

Assign to Steven Lee for filing the implementation bugs and link those to this user story bugs.

No longer depend on bug 908495. The implementation will go for bug 987040.

Add latest text selection & copy/Paste UX spec.

Hi Carol, for text selection, we need your help to provide 2 small icons, please refer to spec p.4, the bottom Notes part, there are Tilt cursor handles, one tilts to the right and one to the left. Thank you.

Hi Carol, we also need your help to provide the bubble icons and layout spec for this. Thank you.

Hi Morris, The attachment is the visual spec for "Text Selection". Let me know if you have any question,thanks!

Update Text_Selection_Visual Spec:Added Utility Bubble menu UI Spec.

Added the test cases. - https://moztrap.mozilla.org/manage/cases/?filter-tag=2617&filter-product=16&filter-productversion=177&pagenumber=1&pagesize=100&sortfield=created_on&sortdirection=desc

Carol, thanks for the spec. @Alive, the layout spec and icons are out, please proceed the gaia work, thank you.

Need functional test, move to 2.1

Hi Carol, I need more UI information for text-selection, like dialog background color, item size, distance btw dialog and selected box... etc.

text selection visual spec update: "Utility bubble menu" corner radius: 2px

The latest UX spec update. p.14 Revising “Dismiss keyboard” description p.15 Revising “A lot of text selected” rule p.16 Revising the typo

Latest UX spec update: p.14 Revising “Dismiss keyboard” description p.15 Adding “Mode transition” (for bug 1016184.)

Here is the Updated UX spec for FxOS 2.1. Mainly adding non-editable text selection.

Team, can you confirm that the initial selection and handles also work right to left? For example: if I tap on a letter, can I then select more text by dragging left (i.e. from the right)? The spec implies this should be possible but I want to confirm this will actually work for 2.1 planning. Thanks!

@Stephany, do you mean p.5 Single Handle in the spec? @Bruce & CJ, can we do this in 2.1?

Hi Stephany, RTL selection is supported in current implementation, thanks.

Resolving as fixed based on comment #25. Thank you, Howie! It looked good on 2.0 but I wanted to check.

Clear ni since Howie had given answer.

Two dependent bugs are still in progress, reopen this bug.

Update text selection Visual spec As offline discussion with George & Omega. Spec Changed: 1. dialog box-shadow:0.2rem 0.2rem 0.4rem 0 rgba(0, 0, 0, 0.4) 2. divider color: #596466 thanks!

Updated UX spec. Adding handle tilt rules.

Updated UX spec. Removing 2 or more rows rule for handle tilt Adding cases: scrolling, overscrolling, zooming, orientation changing, and scrolling iFrame

Hi .. will this also work in content editable text sections? Many forums and other web sites and increasingly apps rely on rich text and thats provided via content editable, vs just the plain text you get in text area so if this bug is being fixed will it also work in these for rich text?

(In reply to James from comment #32) > Hi .. will this also work in content editable text sections? Many forums and > other web sites and increasingly apps rely on rich text and thats provided > via content editable, vs just the plain text you get in text area so if this > bug is being fixed will it also work in these for rich text? Yes. It will work in both plain text and rich text.

Update UX spec for 2.2.

this is not related to RTL but it's 2.2 feature

UX spec update Password Input: Allow only "Select All" and "Paste" in password input

Hi, Here is a simple feedback about the new cut/paste behavior. I see from the spec in attachment 8548759 [details] that there is a behavior difference depending on when the user copied text (before/after 15 sec). As a user I find this confusing, and I'd rather always see the "paste" button. However I understand this can be painful to always see this button so maybe we miss a second button to clear the clipboard. NI UX about this feedback.

> However I understand this can be painful to always see this button so maybe > we miss a second button to clear the clipboard. Or a button to dismiss the copy & paste menu buttons? NI UX for comment #37

(In reply to Julien Wajsberg [:julienw] from comment #37) > Hi, > Here is a simple feedback about the new cut/paste behavior. > I see from the spec in attachment 8548759 [details] that there is a behavior > difference depending on when the user copied text (before/after 15 sec). As > a user I find this confusing, and I'd rather always see the "paste" button. Normally users need to "long press" to activate text selection. However, since copy usually followed by paste immediately(the intention is clear), we let users to paste text by single click in 15 seconds. If it exceeds 15 seconds, users would need to long press to activate text selection and paste the text. The reason is that after a period, it is more possible that they already forget the copied text and only want to switch the cursor by single click. You can also find similar flow on Android. > However I understand this can be painful to always see this button so maybe > we miss a second button to clear the clipboard. I think it is complex to users, since we don't clear copied text on laptop or smartphones.

Attach the latest spec from bug 1217757.

Attach the latest spec from bug 1263578.