Closed
Bug 1103362
Opened 11 years ago
Closed 10 years ago
Text selection carets do not disappear after forced redirect during selection of input box text; selection carets are jumpy.
Categories
(Firefox for Android Graveyard :: Text Selection, defect)
Tracking
(Not tracked)
RESOLVED
INVALID
People
(Reporter: u524404, Assigned: capella)
References
Details
[Reproduce]
Select text in an input box. Have a webpage redirect you while text is selected and you are actively changing the selection.
[What Happens]
The selection carets remain onscreen. The start caret will be in the upper left and will be impossible to grab in tabs that were open upon reproducing the bug, the end caret will remain wherever it was when the page was redirected.
Both carets can be positioned if they can be dragged. Upon scrolling, the start caret will snap to the upper left of the screen. The end caret will remain where it was left. If another tab is selected, the end caret will be in the "original" position. Upon revisiting a tab, the caret will be where it was left. Opening another tab will cause the start caret to be lower down and thus draggable, and the end caret will be offset roughly the displacement of the text that was being selected. Scrolling on a new tab will always reset the two cursors, as will scrolling on a previously opened tab. Sometimes opening or refreshing a new tab will allow the cursors on a previously opened tab to remember their location but that behavior will go away quickly.
[What Should Happen]
The carets disappear. Also, they should not be jumpy during selection in the first place.
This bug may generalize to the selection of non-input-box text.
Updated•11 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
| Assignee | ||
Comment 1•10 years ago
|
||
I can't repro using this test: https://www.dropbox.com/s/rp7ebi1jymjqhd8/test_bug1103362.html?dl=0
Can you clarify / help me see the issue?
Flags: needinfo?(R030t1)
I am unable to reproduce the bug with that code as well. I will mess with it some more when I get time. Relevant information might be that the bug was seen when someone attempted to post to slashdot, while not logged in, from the mobile site.
Thanks for looking. I can't really give you anything more specific, and I haven't seen it again after trying to reproduce it (mainly because the timing of the website in question is unpredictable, but I believe I reproduced the conditions I saw it in). I'm not sure what else would be useful to add to the testcase. Apologies.
Flags: needinfo?(R030t1)
| Assignee | ||
Comment 3•10 years ago
|
||
I'll hold this open until 1/31/15 in case you run into it again.
Assignee: nobody → markcapella
Status: NEW → ASSIGNED
| Assignee | ||
Updated•10 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → INVALID
Updated•4 years ago
|
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•