Closed
Bug 947214
Opened 9 years ago
Closed 5 years ago
Selection in non-focused inputs does not display
Categories
(Firefox for Metro Graveyard :: Theme, defect)
Tracking
(Not tracked)
RESOLVED
INCOMPLETE
People
(Reporter: manuela.muntean, Unassigned)
References
Details
(Whiteboard: p=5)
Attachments
(1 file)
190.66 KB,
video/mp4
|
Details |
- 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
Updated•9 years ago
|
Blocks: metrov1backlog
Updated•9 years ago
|
Whiteboard: [triage]
Keywords: regression
Updated•9 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•9 years ago
|
Whiteboard: [defect] p=0 → [selection][defect] p=0
![]() |
||
Comment 1•9 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•9 years ago
|
||
May require platform and theme changes.
Updated•9 years ago
|
Priority: -- → P3
Updated•9 years ago
|
Target Milestone: --- → Firefox 30
Comment 3•9 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 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•9 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•9 years ago
|
Assignee: nobody → sfoster
Reporter | ||
Comment 4•9 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)
Comment 5•9 years ago
|
||
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•9 years ago
|
||
I'm marking as worksforme. Feel free to comment and re-open if you disagree.
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → WORKSFORME
![]() |
||
Comment 7•9 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.)
Comment 8•9 years ago
|
||
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•9 years ago
|
QA Contact: jbecerra
Whiteboard: [defect] p=5 s=it-30c-29a-28b.1 → [defect] p=5
Updated•9 years ago
|
Status: REOPENED → NEW
Updated•9 years ago
|
Whiteboard: [defect] p=5 → p=5 r=ff30
Target Milestone: Firefox 30 → ---
![]() |
||
Comment 9•9 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)
Comment 10•9 years ago
|
||
OK Jim, I'll remove it from blocking fx30. Thanks.
Flags: needinfo?(mmucci)
Priority: P2 → --
Whiteboard: p=5 r=ff30 → p=5
Comment 11•8 years ago
|
||
Removing the [regression] tag as this issue mimics fxdesktop and is considered a new feature as per comment #7 and comment #8
Keywords: regression
Comment 12•5 years ago
|
||
Mass close of bugs in obsolete product https://bugzilla.mozilla.org/show_bug.cgi?id=1350354
Status: NEW → RESOLVED
Closed: 9 years ago → 5 years ago
Resolution: --- → INCOMPLETE
You need to log in
before you can comment on or make changes to this bug.
Description
•