Selection in non-focused inputs does not display

RESOLVED INCOMPLETE

Status

RESOLVED INCOMPLETE
5 years ago
a year ago

People

(Reporter: manuela.muntean, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: p=5)

Attachments

(1 attachment)

(Reporter)

Description

5 years ago
- 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
(Reporter)

Updated

5 years ago
Blocks: 885383
Whiteboard: [triage]

Updated

5 years ago
Blocks: 838081

Updated

5 years ago
Blocks: 861680
No longer blocks: 838081
Whiteboard: [triage]
Keywords: regression

Updated

5 years ago
Summary: Defect - Selection in non-focused inputs does not display → Selection in non-focused inputs does not display
Whiteboard: [defect] p=0

Updated

5 years ago
Whiteboard: [defect] p=0 → [selection][defect] p=0

Updated

5 years ago
Blocks: 957244

Comment 1

5 years ago
May be in platform and req theme and platform
OS: Windows 8 → Windows 8.1
Whiteboard: [selection][defect] p=0 → [defect] p=5

Comment 2

5 years ago
May require platform and theme changes.

Updated

5 years ago
Priority: -- → P3

Updated

5 years ago
Target Milestone: --- → Firefox 30
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.
Flags: needinfo?(manuela.muntean)

Updated

5 years ago
Status: NEW → ASSIGNED
Priority: P3 → P2
QA Contact: jbecerra
Whiteboard: [defect] p=5 → [defect] p=5 s=it-30c-29a-28b.1

Updated

5 years ago
Assignee: nobody → sfoster
(Reporter)

Comment 4

5 years ago
> 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."
Flags: needinfo?(manuela.muntean)
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?
I'm marking as worksforme. Feel free to comment and re-open if you disagree.
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → WORKSFORME

Comment 7

5 years ago
(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.)
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.
Assignee: sfoster → administration
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---

Updated

5 years ago
QA Contact: jbecerra
Whiteboard: [defect] p=5 s=it-30c-29a-28b.1 → [defect] p=5

Updated

5 years ago
Status: REOPENED → NEW

Updated

5 years ago
Whiteboard: [defect] p=5 → p=5 r=ff30
Target Milestone: Firefox 30 → ---

Comment 9

5 years ago
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.
Flags: needinfo?(mmucci)
OK Jim, I'll remove it from blocking fx30.  Thanks.
Flags: needinfo?(mmucci)
Priority: P2 → --
Whiteboard: p=5 r=ff30 → p=5
Removing the [regression] tag as this issue mimics fxdesktop and is considered a new feature as per comment #7 and comment #8
Keywords: regression
Mass close of bugs in obsolete product https://bugzilla.mozilla.org/show_bug.cgi?id=1350354
Status: NEW → RESOLVED
Last Resolved: 5 years agoa year ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.