947214 - Selection in non-focused inputs does not display

Status: RESOLVED INCOMPLETE

(Firefox for Metro Graveyard :: Theme, defect)

Description

[Manuela Muntean [Away]]

- with latest Nightly, 2013-12-05, on Win 8 64-bit:

STR

1. In Metro mode, open https://bugzilla.mozilla.org/attachment.cgi?id=765417
2. Select text in the lower text area using the mouse
3. Click the upper text area

result: selection goes away in lower text area

4. Hit the Tab key

AR: selection comes back
ER: selection shouldn't come back

Note: same behavior in desktop mode

Comment 1

[Jim Mathies [:jimm]]

May be in platform and req theme and platform

Comment 2

[Jim Mathies [:jimm]]

May require platform and theme changes.

Comment 3

[Sam Foster [:sfoster] (he/him)]

I'm not sure I understand the bug here. I get: 
2) Select text in lower textarea with mouse
Result: text has orange highlight, but no monocle grabbers (as expected)
3) Click in upper textarea
Result: focus and edit caret moves to upper text area. Selection disappears from lower textarea (also as expect)
4) Hit TAB key to place focus back in the lower text area. 
Result: previous selection in this texarea is restored 

This seems like the desired behavior to me? Furthermore, if I make selections with touch I get the same behaviour - which seems like a good thing as touch selections can be more time-consuming to produce and shouldn't be thrown away if possible.

Comment 4

[Manuela Muntean [Away]]

> I'm not sure I understand the bug here. I get: 
> 2) Select text in lower textarea with mouse
> Result: text has orange highlight, but no monocle grabbers (as expected)
> 3) Click in upper textarea
> Result: focus and edit caret moves to upper text area. Selection disappears
> from lower textarea (also as expect)
> 4) Hit TAB key to place focus back in the lower text area. 
> Result: previous selection in this texarea is restored 

Indeed, this is what I'm seeing with the latest Nightly on a PC with Win 8 64-bit.
 
> This seems like the desired behavior to me? Furthermore, if I make
> selections with touch I get the same behaviour - which seems like a good
> thing as touch selections can be more time-consuming to produce and
> shouldn't be thrown away if possible.

I don't know if this is the desired behavior. I've logged this bug as a follow-up for bug 885383, since I can reproduce the first part mentioned in comment 0 of that bug, which is:

"STR:
1) select text in the lower text area using the mouse
2) click the upper text area
result: selection goes away in lower text area

3) tab
result: selection comes back

The background highlight for selection in non-focused edits is messed up."

Comment 5

[Sam Foster [:sfoster] (he/him)]

Attachment: Video capture of selection highlight behavior

This short video shows me making a selection in one input, tabbing to the next field and then back again. The initial selection loses its highlight when not focused and it gets it back again when it regains focus. There's no oddness here with the monocles - I think this is resolved works for me?

Comment 6

[Sam Foster [:sfoster] (he/him)]

I'm marking as worksforme. Feel free to comment and re-open if you disagree.

Comment 7

[Jim Mathies [:jimm]]

(In reply to Sam Foster [:sfoster] from comment #5)
> Created attachment 8371750 [details]
> Video capture of selection highlight behavior
> 
> This short video shows me making a selection in one input, tabbing to the
> next field and then back again. The initial selection loses its highlight
> when not focused and it gets it back again when it regains focus. There's no
> oddness here with the monocles - I think this is resolved works for me?

The bug was about the fact that the non-focused text selection isn't highlighted in any way. So you are seeing the bug, however, this mimics desktop behavior, so it's expected. If we think that for a touch centric browser this should not be the case, we can reopen and try to figure out how to highlight non-focused selected text.  This would be controlled someplace down in platform code. (ehsan would probably know if we decide to reopen and attempt a fix.)

Comment 8

[Sam Foster [:sfoster] (he/him)]

I'm fine with reopening to try and highlight non-focused selection. This is a new feature not a defect though, and not a regression as described. I guess this got lumped in with other more serious/pressing selection bugs and inherited their priority. I'll put it back on the stack.

Comment 9

[Jim Mathies [:jimm]]

Hey marco, I don't think this needs to block fx30, it's a pretty low priority bug. The behavior here matches desktop, some might not even consider this a bug. We need to see if users come up with compelling use cases which would make this a priority over other selection work.

Comment 10

[Marco Mucci [:MarcoM]]

OK Jim, I'll remove it from blocking fx30.  Thanks.

Comment 11

[Kamil Jozwiak [:kjozwiak]]

Removing the [regression] tag as this issue mimics fxdesktop and is considered a new feature as per comment #7 and comment #8

Comment 12

[Firefox Bug Husbandry Bot]

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