This is actually two related bugs:
If a selection is formed with a double click, the baseOffset and extentOffset are the same, which is
If the identical selection is made by dragging, the offsets are different, and correct, with one exception - if
the selection is made by dragging right to left, the baseOffset will be greater than the extentOffset (e.g.
the order of the offsets, and presumably the nodes as well, is reversed).
Created attachment 4806 [details]
I am not sure about dragging from right to left, but the double-click behavior certainly looks like a bug.
Created attachment 5239 [details]
Internally, our SelectionController uses the "base" to refer to the DOM
Position where the mouse was when the user began creating the selection, and
"extent" to refer to the DOM Position where the mouse was when the user
finalized the selection. So the base will come before the extent for
selections created from left to right and the extent will come before the base
for selections created from right to left. Given this definition of
base/extent, it makes sense that the base/extent would be equal for selections
created using a double or triple click, since the user started and finalized
the selection at the same DOM Position.
The SelectionController also has start() and end(), which refer to the DOM
Positions where the Selection actually starts/ends.
start/end! We support the anchor/focus properties from Mozilla's Selection
object API, but anchor/focus just return base/extent. In Mozilla's
documentation, anchor/focus are actually defined to be start/end (as start/end
were just defined above). So this change changes anchor/focus, and leaves
This patch also adds getRangeAt from Mozilla's API, outlines the rest of the
Next, I want to make the JS Selection object a wrapper for the internal
SelectionController object, instead of a wrapper for a KHTMLPart like it is
now. Then I want to support the rest of the Mozilla Selection object API
(except the methods that only make sense for discontinuous selections).
Created attachment 5241 [details]
A few tweaks. This patch also adds an updateLayout call inside
VisiblePosition::init. Instead of sprinkling the editing/selection code with
updateLayouts, I think we should just call it when whenever we're about to
create a VisiblePosition. I should ask darin/harrison about this and then
remove all the updateLayout calls from the editing code.
Created attachment 5242 [details]
attaching the correct patch
Created attachment 5243 [details]
attaching the right patch this time, honest to god.
It looks like not all of the updateLayout calls in the editing code are used to ensure valid VisiblePositions,
so not all updateLayouts could be removed after adding an updateLayout to VisiblePosition::init
Comment on attachment 5243 [details]
getRangeAt should return a PassRefPtr.
Made two changes before landing. In FireFox, anchor/focus are the equal to the start/end of the
selection, but reflect the direction in which the selection was made by the user. That does not mean that
they are base/extent, since the base/extent don't reflect expansion. Also made darin's change.