865654 - Coordinates near text input boundaries passed to caretPositionFromPoint product wrong offsets

Status: RESOLVED FIXED

(Core :: DOM: Core & HTML, defect)

Description

[Jim Mathies [:jimm]]

Attachment: testcase

STR:

If you attempt to use caretPositionFromPoint with coordinates that aren't in the very center of text inputs the resulting offsets can be off, usually near at the beginning or end of the control.

This can play havoc with touch input / selection on mobile devices that rely on caretPositionFromPoint for setting selection or caret position.

STR:

1) open test case
2) open web console
3) click the mouse in the center of the text in the control

you should see a valid offset value.

4) move the mouse down to the white space below text and click again.

the caret will move to the end of the control and in the console you should see an offset of 924.

Comment 1

[Jim Mathies [:jimm]]

If you tweak the test case by setting a higher height value on the input it's easier to see the problem.

Comment 2

[:Margaret Leibovic]

Thanks for filing this, jimm! This sounds like the issue I was seeing with bug 864582.

Comment 3

[Scott Johnson (:jwir3)]

Hm, so the problem here is that we have nested frames. If you open the testcase I am attaching with this comment (same testcase as Jim posted, just edited to make the height of the input larger) with the layout debugger setup to enable Visual Debugging, you'll see that there is a frame inside of the input element that contains the actual text.

In order for caretPositionFromPoint to work, we get the offset from a point within a given frame. This works by first detecting which frame the point resides in. In the case of text inputs, though, we don't want to expose the anonymous content in the text control, so a decision was made to always utilize the inner frame of the text control (which contains the content), hence the situation we have here. 

One thing I might ask, though, is "What would it be expected to do?". I guess it seems like this should probably find the offset in the content that's vertically aligned with the click point in the text control, which we might be able to do in this case. For textareas, though, if you were to click in the whitespace at the bottom of the control element like this, I would argue that the behavior should do what is happening with the input element right now. 

So, it seems like what we need to do is specialize between textareas and input elements, which are apparently using the same codepaths right now...

Comment 4

[Scott Johnson (:jwir3)]

Attachment: testcase-modified

Comment 5

[Scott Johnson (:jwir3)]

Attachment: b865654

This patch adds a test for the problem seen in this bug, and fixes the problem by only adjusting offsets (the cause of the problem) for text areas. Other input elements don't need their offsets adjusted.

Comment 6

[Scott Johnson (:jwir3)]

Inbound:
https://hg.mozilla.org/integration/mozilla-inbound/rev/4fd41b93f97c

Comment 7

[Phil Ringnalda (:philor)]

Outbound: http://hg.mozilla.org/integration/mozilla-inbound/rev/7480571fa34e for https://tbpl.mozilla.org/php/getParsedLog.php?id=23298138&tree=Mozilla-Inbound

Comment 8

[Scott Johnson (:jwir3)]

Re-inbound: 
https://hg.mozilla.org/integration/mozilla-inbound/rev/65c09310a0b3

Comment 9

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/65c09310a0b3

Comment 10

[Jim Mathies [:jimm]]

Attachment: textarea

This is still a little broken with text area boundaries, should I file a follow up?

Comment 11

[Scott Johnson (:jwir3)]

(In reply to Jim Mathies [:jimm] from comment #10)
> Created attachment 761418 [details]
> textarea
> 
> This is still a little broken with text area boundaries, should I file a
> follow up?

Jim:

Are you talking about if you expand the text area and then move the mouse over an area of whitespace to the right of a given line? If so, then I thought there was a bug on this already... let me see if I can find it.

Comment 12

[Jim Mathies [:jimm]]

(In reply to Scott Johnson (:jwir3) from comment #11)
> (In reply to Jim Mathies [:jimm] from comment #10)
> > Created attachment 761418 [details]
> > textarea
> > 
> > This is still a little broken with text area boundaries, should I file a
> > follow up?
> 
> Jim:
> 
> Are you talking about if you expand the text area and then move the mouse
> over an area of whitespace to the right of a given line? If so, then I
> thought there was a bug on this already... let me see if I can find it.

That's one problem, here are two test cases:

1) move your mouse to the lower edge of the textarea, you'll notice there is a ~3 pixel inner boundary where cpfp returns 2 rather than a correct text offset.

2) move your mouse to any text line and move right to the end of the text. You'll notice that after the cursor moves past the last character, cpfp will return an offset equal to the last character in the textarea, rather than the offset at the end of the line.

Comment 13

[Scott Johnson (:jwir3)]

(In reply to Jim Mathies [:jimm] from comment #12)
> (In reply to Scott Johnson (:jwir3) from comment #11)
> > (In reply to Jim Mathies [:jimm] from comment #10)
> > > Created attachment 761418 [details]
> > > textarea
> > > 
> > > This is still a little broken with text area boundaries, should I file a
> > > follow up?
> > 
> > Jim:
> > 
> > Are you talking about if you expand the text area and then move the mouse
> > over an area of whitespace to the right of a given line? If so, then I
> > thought there was a bug on this already... let me see if I can find it.
> 
> That's one problem, here are two test cases:
> 
> 1) move your mouse to the lower edge of the textarea, you'll notice there is
> a ~3 pixel inner boundary where cpfp returns 2 rather than a correct text
> offset.
>
> 2) move your mouse to any text line and move right to the end of the text.
> You'll notice that after the cursor moves past the last character, cpfp will
> return an offset equal to the last character in the textarea, rather than
> the offset at the end of the line.

Ok, so these problems and the above mentioned problem in comment 11 are basically the same thing. What is happening is that the frame for a given point is being incorrectly returned (since there's an anonymous document structure inside of the text area). I thought there was a bug for this already, but a precursory search didn't turn anything up. So, yes, I think this should be a followup bug. 

As an aside, I think what we need to do for textareas is, given a point, find the nearest text frame to that point under certain conditions. I'm not 100% sure how this will work yet, though, since it's unclear that this will always return the correct frame.

Comment 14

[Scott Johnson (:jwir3)]

Thanks, Jim!