Text selection does not place grippers left or right of the tapped word

RESOLVED INCOMPLETE

Status

enhancement
P4
normal
RESOLVED INCOMPLETE
6 years ago
2 years ago

People

(Reporter: jbecerra, Unassigned)

Tracking

Trunk
x86_64
Windows 8.1
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [selection] p=3)

(Reporter)

Description

6 years ago
Tested on 2013-04-24 using a nightly built from http://hg.mozilla.org/mozilla-central/rev/fef5f202b2dc

While verifying bug 862054 I noticed that the grippers do not appear left or right of the word I tapped on for selection. This makes text selection feel a little random. We should be following http://msdn.microsoft.com/en-us/library/windows/apps/hh465334.aspx and we should have parity with IE.

Steps:
1. Go to https://developer.mozilla.org/en-US/docs/HTML/HTML_Elements/textarea#HTML_Content
2. In the text area, tap on one of the words like "something"

Expected: Gripper should appear at the beginning (left) or at the end (right) of the word depending on where you tapped. From then it is easy to select the word using the ripper.

Actual: Caret appears midword and then gripper selection can be a little random. When the grippers do appear and you start to select something, it looks like it is selecting up to the next space ccharacter, too.
(Reporter)

Updated

6 years ago
Blocks: 862054
Summary: defect - text selection does not place grippers left or right of the tapped word → Defect - text selection does not place grippers left or right of the tapped word
Whiteboard: feature=defect u=metro_firefox_user c=content_features p=0

Updated

6 years ago
OS: Windows 8 → Windows 8 Metro

Updated

6 years ago
Severity: normal → enhancement

Updated

6 years ago
No longer blocks: 862054

Updated

6 years ago
Component: General → Input
p=8 maybe? We might be able to use the selection controller to move the caret around words after it's placed in the word. But detecting where it is initially so we know where to move it might be tough. DOM selection really doesn't have anything like this built in at this point.

Updated

6 years ago
Priority: -- → P4
This is marked priority=4, effort=8. I might propose kicking this from the mvp list.
Whiteboard: feature=defect u=metro_firefox_user c=content_features p=0 → feature=defect u=metro_firefox_user c=content_features p=0 [decision-needed]
At a P4 it is technically off the list.
Priority: P4 → --

Updated

6 years ago
Whiteboard: feature=defect u=metro_firefox_user c=content_features p=0 [decision-needed] → [selection] feature=defect u=metro_firefox_user c=content_features p=0 [decision-needed]
No longer blocks: metrov2defect&change
Summary: Defect - text selection does not place grippers left or right of the tapped word → Text selection does not place grippers left or right of the tapped word
Whiteboard: [selection] feature=defect u=metro_firefox_user c=content_features p=0 [decision-needed] → [selection] [defect] p=0 [decision-needed]
Blocks: 957244
No longer blocks: caret-sel

Updated

5 years ago
Whiteboard: [selection] [defect] p=0 [decision-needed] → [selection] [defect] p=3
Priority: -- → P1
Priority: P1 → P2
Priority: P2 → P4
Whiteboard: [selection] [defect] p=3 → [selection] p=3
Isn't the observed behavior correct for Metro? ie: single tapping into a word produces a caret-at-point? This is consistent with FF Desktop, Fennec/Android, and IE.

Note that IE positions it to one side of the word so that a second tap performs text selection and places the second handle on the other side of the word.

(Fennec uses longtap to do word selection (bounded by and not including spaces), and places handles on either side. Desktop uses double-tap for word selection, and Metro uses longtap, which opens a context menu and allows word selection via option).
Assignee: nobody → markcapella
Status: NEW → ASSIGNED
(In reply to Mark Capella [:capella] from comment #4)
> Isn't the observed behavior correct for Metro? ie: single tapping into a
> word produces a caret-at-point? This is consistent with FF Desktop,
> Fennec/Android, and IE.
> 
> Note that IE positions it to one side of the word so that a second tap
> performs text selection and places the second handle on the other side of
> the word.
> 
> (Fennec uses longtap to do word selection (bounded by and not including
> spaces), and places handles on either side. Desktop uses double-tap for word
> selection, and Metro uses longtap, which opens a context menu and allows
> word selection via option).

I feel so. The current behavior will also change if we get single tap word selection working.
Can you clarify a bit more? (I'm late to this conversation :) )

re: |if we get single tap word selection working|, would be the new behavior for Metro? (Versus long-tapping -or- selection by context menu option ?
(In reply to Mark Capella [:capella] from comment #6)
> Can you clarify a bit more? (I'm late to this conversation :) )
> 
> re: |if we get single tap word selection working|, would be the new behavior
> for Metro? (Versus long-tapping -or- selection by context menu option ?

Oleg was looking at getting single tap selection working. I can't find the bug though.
Freeing up for now ...
Assignee: markcapella → nobody
Status: ASSIGNED → NEW
OS: Windows 8 Metro → Windows 8.1
Mass close of bugs in obsolete product https://bugzilla.mozilla.org/show_bug.cgi?id=1350354
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.