Text isn't visually selected after dragging the caret out of view
Categories
(Firefox for Android Graveyard :: Text Selection, defect)
Tracking
(Not tracked)
People
(Reporter: csheany, Unassigned)
References
(Blocks 1 open bug)
Details
Attachments
(2 files)
User Agent: Mozilla/5.0 (Android 7.1.1; Tablet; rv:68.0) Gecko/68.0 Firefox/68.0
Steps to reproduce:
- Open this bug
- Scroll to the description
- Long press (this) word
- Drag the caret up past the toolbar
Actual results:
Text doesn't appear to be selected. Dragging the caret back down on to the page reveals that it was.
Expected results:
To be determined
Comment 1•6 years ago
|
||
Is the "toolbar" mentioned in step 4 the copy/paste floating toolbar, or the address bar? A screenshot with the actual result would be helpful.
Comment 4•6 years ago
|
||
Hi,
I was not able to reproduce the issue on the latest Nightly 68.0a1 (2019-04-20) with Samsung Galaxy Tab S3 (Android 8.0).
I long-tapped the word "(this)" and it was selected as expected. When I dragged the carrot above the floating toolbar, the text was selected as expected. Maybe I did not understand the issue correctly.
Csheany, could you help me with a short video?
Thanks!
Thank you Mira :)
As requested...
Comment 7•6 years ago
•
|
||
I can reproduce the issue.
(In reply to miralobontiu from comment #4)
When I dragged the carrot above the floating toolbar, the text was selected as expected. Maybe I did not understand the issue correctly.
My understanding is that, to trigger the issue:
- The page has to be scrolled down a bit, not scrolled all the way to the top.
- The caret needs to be dragged all the way to the top of the screen, so that the selection is extended to lines which are scrolled out of the view at the top, triggering "scroll into view" logic that should scroll the page (and the bug is that the page doesn't scroll).
My first thought was a regression from bug 1516056, but that doesn't seem to be the case: the bug reproduces at least as far back as the Firefox 66 release.
A regression window would be nice for further diagnosis (assuming this is a regression at all).
Comment 9•6 years ago
|
||
(In reply to csheany from comment #8)
The page does scroll but the selection isn't tracked.
Thanks for clarifying; I misunderstood the problem.
I tested it again on a tablet this time, and there I see the behaviour you describe (and which the video also shows).
In an earlier release (I tested Firefox 57), I see that reaching the top of the screen makes the selection stop expanding (and no scrolling happens).
It would be interesting to find out when the behaviour changed.
Comment 10•6 years ago
|
||
The behaviour changed in bug 1404854. The described behaviour (page scrolls, but selection is not extended visually) occurs ever since that fix landed.
I don't really think this can be described as a "regression", as prior to that the page did not scroll at all. It's more like a deficiency in the ability to extend a selection past the edge of the screen, which has been in place ever since that ability was introduced.
Comment 11•6 years ago
|
||
OK, so the issue is the page scrolled but the selection range doesn't extend. Blocking Bug 1124074 so that I can come back to this bug.
Comment 12•6 years ago
|
||
The priority flag is not set for this bug.
:st3fan, could you have a look please?
For more information, please visit auto_nag documentation.
Comment 13•6 years ago
|
||
Hello,
I Tested this issue on the latest Nightly 68.0a1 (2019-05-14) using a Samsung Galaxy S8+ and the issue no longer occurs, probably as a result of bug 1540545 being fixed.
I will mark this issue as fixed.
![]() |
||
Updated•6 years ago
|
Updated•5 years ago
|
Description
•