Summary: | Bug with baseOffset and extentOffset in selections | ||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Sam Schillace <sam> | ||||||||||||
Component: | HTML Editing | Assignee: | Justin Garcia <justin.garcia> | ||||||||||||
Status: | RESOLVED FIXED | ||||||||||||||
Severity: | Normal | CC: | ap | ||||||||||||
Priority: | P2 | ||||||||||||||
Version: | 420+ | ||||||||||||||
Hardware: | Mac | ||||||||||||||
OS: | OS X 10.4 | ||||||||||||||
Attachments: |
|
Description
Sam Schillace
2005-09-09 10:57:33 PDT
Created attachment 4806 [details]
test case
I am not sure about dragging from right to left, but the double-click behavior certainly looks like a bug. Created attachment 5239 [details]
patch
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.
Unfortunately our JavaScript Selection object doesn't allow access to the
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
base/extent alone.
This patch also adds getRangeAt from Mozilla's API, outlines the rest of the
API, and cleans up the JavaScript Selection object.
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]
patch-2
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]
patch-3
attaching the correct patch
Created attachment 5243 [details]
patch-4
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]
patch-4
r=me
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. |