Bug 6350 - Selection shouldn't exclude collapsed whitespace
Summary: Selection shouldn't exclude collapsed whitespace
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: HTML Editing (show other bugs)
Version: 420+
Hardware: Macintosh OS X 10.4
: P2 Normal
Assignee: Nobody
Keywords: HasReduction
Depends on: 23793
  Show dependency treegraph
Reported: 2006-01-03 03:29 PST by Alexey Proskuryakov
Modified: 2017-07-18 08:27 PDT (History)
5 users (show)

See Also:

test case (1.51 KB, text/html)
2006-01-03 03:30 PST, Alexey Proskuryakov
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Alexey Proskuryakov 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.
Comment 1 Alexey Proskuryakov 2006-01-03 03:30:34 PST
Created attachment 5446 [details]
test case
Comment 2 Justin Garcia 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).
Comment 3 Alexey Proskuryakov 2007-12-29 11:17:38 PST
See also: bug 15256.