Problem with edit cursor in scaled content editable

RESOLVED FIXED in Firefox 68



5 months ago
4 months ago


(Reporter: dalius.dobravolskas, Assigned: heycam)



Firefox Tracking Flags

(firefox-esr60 wontfix, firefox65 wontfix, firefox66 wontfix, firefox67 wontfix, firefox68 fixed)



(2 attachments)

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:65.0) Gecko/20100101 Firefox/65.0

Steps to reproduce:

I have created large contentEditable="true" div and scaled it down using css transform.

Actual results:

I can't move cursor more than x pixels in content editable where x is screen width / scale. E.g. if screen width is 1024 points, div width is 10000 points and scale is 0.1 that means I can't move cursor more than 100 points in div (that's approximate math but you can get different result by simply resizing window).

Here is sample demonstrating the problem:

Expected results:

User should be able to move cursor anywhere in the window like it is possible in textarea (included in sample) or Chromium with contentEditable.

I can reproduce the issue on windows10.

And also affected caret browsing mode(F7).
( )

Component: Untriaged → Layout
Ever confirmed: true
OS: Unspecified → All
Product: Firefox → Core
Version: 65 Branch → Trunk

Looks like it's just about the caret rendering. If I e.g. keep pressing the Right arrow past the edge where it doesn't want to move, and then press Shift+Right to start selecting, the selection starts where I would expect.

Priority: -- → P3

This chunk of code:

clamps the position of the caret so that it is within the bounds of its closest scrolled frame ancestor, so that if we are e.g. scrolled all the way to the right, and the text frame that contains the caret goes right up to the edge of the scrolled frame, the caret will still be visible. It doesn't take any transforms into account though.

Rather than clamping based on the size of the scrolled frame, we should probably clamp to the edge of the frame the caret is in, but only do that if the caret rect would fall out of the scrolled frame's bounds (and take transforms into account when doing this check). I think we don't want to clamp unconditionally, since it looks better to have the caret rendered just past the edge of the element it's in if that area can be shown if we're scrolled to the right position.

Turns out the caret clamping is broken anyway; filed bug 1539720 for that.

I have a patch that I think should do the right thing wrt clamping with transforms, but no way to really test it given something else has broken the clamping. (I think the clamping code itself is OK, so maybe something with painting has broken that.)

So I'm tempted just to add a band-aid to disable the clamping (in case it is actually working in some cases I haven't tested) if there's a transform present.

Assignee: nobody → cam

Thank you for the test cases, Dalius and Alice.

Pushed by
Disable caret clamping if transforms are present. r=dholbert
Backout by
Backed out changeset 0c32d04c0665 for reftest failures at /bugs/1529492-1.html on a CLOSED TREE.

You should probably add the reftest to:

Or at least set ui.caretBlinkTime to -1 to avoid the test randomly failing.

Thanks, though I thought that pref was set automatically in testing/profiles/reftest/user.js. I'll try another run with it set explicitly to see if it sticks...

Moving the test to test_reftests_with_caret.html did work, thanks. :)

Flags: needinfo?(cam)
Pushed by
Disable caret clamping if transforms are present. r=dholbert

Looks like we need one pixel of fuzziness there.

Flags: needinfo?(cam)
Pushed by
Disable caret clamping if transforms are present. r=dholbert
Closed: 4 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla68
You need to log in before you can comment on or make changes to this bug.