Coordinates near text input boundaries passed to caretPositionFromPoint product wrong offsets

RESOLVED FIXED in mozilla24

Status

()

Core
DOM
RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: jimm, Assigned: jwir3)

Tracking

(Blocks: 1 bug)

Trunk
mozilla24
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [selection] )

Attachments

(3 attachments, 1 obsolete attachment)

(Reporter)

Description

5 years ago
Created attachment 741820 [details]
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.
(Reporter)

Comment 1

5 years ago
If you tweak the test case by setting a higher height value on the input it's easier to see the problem.
(Reporter)

Updated

5 years ago
Blocks: 865660

Comment 2

5 years ago
Thanks for filing this, jimm! This sounds like the issue I was seeing with bug 864582.
Blocks: 864582
(Reporter)

Updated

5 years ago
Whiteboard: [selection]
(Assignee)

Comment 3

5 years ago
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...
(Assignee)

Comment 4

5 years ago
Created attachment 752563 [details]
testcase-modified
Attachment #741820 - Attachment is obsolete: true
(Assignee)

Comment 5

5 years ago
Created attachment 752597 [details] [diff] [review]
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.
Assignee: nobody → sjohnson
Attachment #752597 - Flags: review?(blassey.bugs)
(Assignee)

Updated

5 years ago
OS: Windows 8 → All
Hardware: x86_64 → All
Attachment #752597 - Flags: review?(blassey.bugs) → review+
(Assignee)

Comment 6

5 years ago
Inbound:
https://hg.mozilla.org/integration/mozilla-inbound/rev/4fd41b93f97c
Target Milestone: --- → mozilla24
https://hg.mozilla.org/mozilla-central/rev/65c09310a0b3
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → mozilla24
(Reporter)

Comment 10

5 years ago
Created attachment 761418 [details]
textarea

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

Comment 11

5 years ago
(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.
(Reporter)

Comment 12

5 years ago
(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.
(Assignee)

Comment 13

5 years ago
(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.
(Reporter)

Updated

5 years ago
Blocks: 882149
(Assignee)

Comment 14

5 years ago
Thanks, Jim!
You need to log in before you can comment on or make changes to this bug.