WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
29217
document.caretRangeFromPoint should take the scroll offset into account before hit testing
https://bugs.webkit.org/show_bug.cgi?id=29217
Summary
document.caretRangeFromPoint should take the scroll offset into account befor...
Xiaomei Ji
Reported
2009-09-11 18:16:51 PDT
Created
attachment 39496
[details]
caretRangeFromPointWithoutScroll.html There are 3 issues: 1. I think the offset in the returned range should be the character/caret offset relative to the whole element, not relative to the viewpoint. Please see the attached file caretRangeFromPointWithoutScroll.html for detailed explanation. 2. If I pass in event.clientX + document.body.scrollLeft and event.clientY + document.body.scrollTop as the x-axis and y-axis to caretRangeFromPoint(), there is a possibility that the range is null which should not. Please see attached file caretRangeFromPointWithScroll.html for detailed explanation. 3. In caretRangeFromPoint(), there is the following code: Node* node = result.innerNode(); if (!node) return 0; Since we do not check whether the 'node' is a Text related node, there is a possibility that a range is created even when the mouse is not pointed in the text area. Please open caretRangeFromPointInNonTextNode.html, click mouse right before the first word "type", in the range created by caretRangeFromPoint(), the node is the Text node, the start/end offset is 0. click mouse several characters ahead of word "type" (the empty space in the left of "type"), although the 'node' is a HTMLParagraphElement, but it has the same visible position as the above, and the range created is the same as above. Is this the correct behavior? I think my assumption is that this function converts mouse position to the character position within an element, so a null range should be returned if click the empty spaces ahead of word "type".
Attachments
caretRangeFromPointWithoutScroll.html
(2.01 KB, text/html)
2009-09-11 18:16 PDT
,
Xiaomei Ji
no flags
Details
caretRangeFromPointWithScroll.html
(1.57 KB, text/html)
2009-09-11 18:17 PDT
,
Xiaomei Ji
no flags
Details
caretRangeFromPointInNonTextNode.html
(1.13 KB, text/html)
2009-09-11 18:18 PDT
,
Xiaomei Ji
no flags
Details
patch
(6.11 KB, patch)
2009-09-12 01:10 PDT
,
Sam Weinig
mjs
: review+
Details
Formatted Diff
Diff
View All
Add attachment
proposed patch, testcase, etc.
Xiaomei Ji
Comment 1
2009-09-11 18:17:32 PDT
Created
attachment 39497
[details]
caretRangeFromPointWithScroll.html
Xiaomei Ji
Comment 2
2009-09-11 18:18:55 PDT
Created
attachment 39498
[details]
caretRangeFromPointInNonTextNode.html
Sam Weinig
Comment 3
2009-09-12 01:06:04 PDT
(In reply to
comment #0
)
> Created an attachment (id=39496) [details] > caretRangeFromPointWithoutScroll.html > > There are 3 issues:
You should really file three bugs if you think there are three issues, one for each of these. I am going to repurpose this bug to represent the first two, since I believe they represent the same issue, that we don't take the scroll offset into account before hit testing (which is the behavior of our elementFromPoint implementation, on which this API is modeled. Our elementFromPoint seems to be /wrong/' in this regard [
bug 29219
]).
Sam Weinig
Comment 4
2009-09-12 01:10:04 PDT
Created
attachment 39507
[details]
patch
Maciej Stachowiak
Comment 5
2009-09-12 01:13:52 PDT
Comment on
attachment 39507
[details]
patch r=me
Sam Weinig
Comment 6
2009-09-12 01:20:07 PDT
Fix landed in
r48333
.
Xiaomei Ji
Comment 7
2009-09-14 11:21:17 PDT
Thanks for the fixing. Filed another 2 bugs representing issue #2 and #3:
https://bugs.webkit.org/show_bug.cgi?id=29247
https://bugs.webkit.org/show_bug.cgi?id=29249
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug