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

Status: RESOLVED INCOMPLETE

(Firefox for Metro Graveyard :: Input, enhancement, P4)

Description

[juan becerra [:juanb]]

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.

Comment 1

[Jim Mathies [:jimm]]

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.

Comment 2

[Allison Naaktgeboren :ally]

This is marked priority=4, effort=8. I might propose kicking this from the mvp list.

Comment 3

[Marco Mucci [:MarcoM]]

At a P4 it is technically off the list.

Comment 4

[Mark Capella [:capella]]

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

Comment 5

[Jim Mathies [:jimm]]

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

Comment 6

[Mark Capella [:capella]]

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 ?

Comment 7

[Jim Mathies [:jimm]]

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

Comment 8

[Jim Mathies [:jimm]]

bug 956697

Comment 9

[Mark Capella [:capella]]

Freeing up for now ...

Comment 10

[Firefox Bug Husbandry Bot]

Mass close of bugs in obsolete product https://bugzilla.mozilla.org/show_bug.cgi?id=1350354