[Webkit-unassigned] [Bug 54535] Stop calling node() and deprecatedEditingOffset() in comparePositions

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Wed Feb 16 00:24:54 PST 2011


https://bugs.webkit.org/show_bug.cgi?id=54535


Ryosuke Niwa <rniwa at webkit.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |darin at apple.com,
                   |                            |enrica at apple.com,
                   |                            |eric at webkit.org,
                   |                            |justin.garcia at apple.com,
                   |                            |leviw at chromium.org,
                   |                            |mjs at apple.com,
                   |                            |ojan at chromium.org,
                   |                            |tony at chromium.org




--- Comment #3 from Ryosuke Niwa <rniwa at webkit.org>  2011-02-16 00:24:54 PST ---
This patch can't be completed at the moment because it regresses editing/deleting/25322-2.html.  In this test, we have an image followed by a br as in:
<div><img src=..><br></div>

We then place the caret at the end of the div, and press delete key.  Because of canononicalization, we end up getting [br, 0] internally for this selection in TypingCommand::deleteKeyPressed.  The problem is when we extend the selection backwards by SelectionController::modify.  The extent in this case is [img, 1] and comparePositions with my patch says they're identical to [br, 0] and VisibleSelection::setBaseAndExtentToDeepEquivalents sets m_baseIsFirst true.  However, this causes all sort of assumptions to break down in DeleteSelectionCommand.

I'm not sure what the correct fix is.  It seems like DeleteSelectionCommand needs to handle these special cases but it's also odd that SelectionController replies on Position comparison functions to determine which positions comes first when they should really be comparing positions visually.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.



More information about the webkit-unassigned mailing list