Closed Bug 1545830 Opened 7 months ago Closed 6 months ago

Text isn't visually selected after dragging the caret out of view

Categories

(Firefox for Android :: Text Selection, defect)

Firefox 68
defect
Not set

Tracking

()

RESOLVED FIXED

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:

  1. Open this bug
  2. Scroll to the description
  3. Long press (this) word
  4. 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

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.

The address bar.

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!

Component: General → Text Selection
Flags: needinfo?(csheany)

Thank you Mira :)

As requested...

Flags: needinfo?(csheany)
Attached video 2019_04_22_08_12_26.mp4

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:

  1. The page has to be scrolled down a bit, not scrolled all the way to the top.
  2. 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).

The page does scroll but the selection isn't tracked.

(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.

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.

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.

The priority flag is not set for this bug.
:st3fan, could you have a look please?

For more information, please visit auto_nag documentation.

Flags: needinfo?(sarentz)

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.

Status: UNCONFIRMED → RESOLVED
Closed: 6 months ago
Resolution: --- → FIXED
Flags: needinfo?(sarentz)
You need to log in before you can comment on or make changes to this bug.