WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED CONFIGURATION CHANGED
6350
Selection shouldn't exclude collapsed whitespace
https://bugs.webkit.org/show_bug.cgi?id=6350
Summary
Selection shouldn't exclude collapsed whitespace
Alexey Proskuryakov
Reported
2006-01-03 03:29:54 PST
If a selection range set via setBaseAndExtent starts or ends with collapsed whitespace, it is excluded from the range, which doesn't happen in Firefox.
Attachments
test case
(1.51 KB, text/html)
2006-01-03 03:30 PST
,
Alexey Proskuryakov
no flags
Details
View All
Add attachment
proposed patch, testcase, etc.
Alexey Proskuryakov
Comment 1
2006-01-03 03:30:34 PST
Created
attachment 5446
[details]
test case
Justin Garcia
Comment 2
2006-01-04 01:23:55 PST
Here's why this happens: Positions passed to Selection::setBaseAndExtent are used to construct VisiblePositions. VisiblePositions take the input position and find its canonical position: the position that is visually equivalent but "deep" and at a rendered offset (this canonical position is referred to internally as a "deep equivalent" and is returned by VisiblePosition::deepEquivalent()) For example: <div><b>hello world</b></div> A VisiblePosition created with the Position (div, 0), would have a "deep equivalent" of (textnode, 0). A VisiblePosition created with the Positions (textnode, 6), (textnode, 7), and (textnode, 8) would all have deep equivalents of (textnode, 8). The behavior you see is caused because SelectionController takes the Positions passed to setBaseAndExxtent, creates VisiblePositions, then sets the base and the extent to the deep equivalents of those VisiblePositions. SelectionController does even more fiddling with its positions. When it creates start/end (from base/ extent), it upstream()s the end and downstream()s the start. Comments in SelectionController claim that this is necessary to "constrain" the selection to the fewest possible nodes, in order to make it canonical for purposes of comparison with other selections. I'm not sure why this is necessary, since VisiblePosition's are already canonical. Both of these things need to be addressed to fix this kind of bug (when ranges change when they are used to make selections).
Alexey Proskuryakov
Comment 3
2007-12-29 11:17:38 PST
See also:
bug 15256
.
Ahmad Saleem
Comment 4
2022-07-30 10:25:51 PDT
I am able to reproduce this bug using attached test case in Safari 15.6 on macOS 12.5 and it shows offSet of 1 & 7 rather than 0 and 8. *** Safari 15.6 on macOS 12.5 *** body.firstChild.nodeValue: \n123456\n anchor: [object Text], offset: 1 focus: [object Text], offset: 7 *** Chrome Canary 106 *** body.firstChild.nodeValue: \n123456\n anchor: [object Text], offset: 0 focus: [object Text], offset: 8 *** Firefox Nightly 105 *** body.firstChild.nodeValue: \n123456\n anchor: [object Text], offset: 0 focus: [object Text], offset: 8 ________ I am not sure on web-spec but just wanted to share latest test results. Thanks!
Radar WebKit Bug Importer
Comment 5
2022-07-30 10:41:38 PDT
<
rdar://problem/97840483
>
Ahmad Saleem
Comment 6
2023-02-25 07:37:06 PST
Fixed by Live Range Selection API. Confirmed on Safari Technology Preview 164. Marking this as "RESOLVED CONFIGURATION CHANGED". Thanks!
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