[Webkit-unassigned] [Bug 19331] New: Drag and drop of links in edit mode violates assert in MoveSelectionCommand::doApply()

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Fri May 30 14:22:51 PDT 2008


http://bugs.webkit.org/show_bug.cgi?id=19331

           Summary: Drag and drop of links in edit mode violates assert in
                    MoveSelectionCommand::doApply()
           Product: WebKit
           Version: 526+ (Nightly build)
          Platform: PC
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: Normal
          Priority: P2
         Component: HTML Editing
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: jonathon.jongsma at collabora.co.uk


When in edit mode (using QtWebKit), if I drag a live link with no text selected
and then drop it somewhere else on the page, I hit an ASSERT in
MoveSelectionCommand::doApply().  I sent a message to the mailing list about
this (https://lists.webkit.org/pipermail/webkit-dev/2008-May/004044.html), but
I'll copy it here for reference:

I'm attempting to add editing support to QtWebKit (e.g.
QWebPage::setEditable()), and it seems to work great for basic editing.
But while playing around with it, I've noticed some bugs related to
drag-and-drop that I'm having trouble chasing down and would appreciate
a bit of guidance.  The browser I'm testing with does not set anything
special for editableLinkBehavior (so it's the default, which means that
links are live in edit mode).

The first problem that I'm running into is the following:
- No text is selected
- page is in edit mode
- click and drag a link
- drop the link somewhere else on the page
-> hits ASSERT in MoveSelectionCommand::doApply()
   - ASSERT(selection.isRange());

So, as far as I can see, the problem is one of the following:
A) we're using the wrong command in this situation (we shouldn't be
using MoveSelectionCommand because there is no current selection)
B) this command should handle the case where there's no selection
instead of just asserting it
C) the drag should not be allowed unless there is a selection (this one
seems wrong to me -- if the editable link behavior is 'live', it seems
they should behave just like normal links, which can be dragged without
an active selection)
D) When a user initiates a drag without anything selected, webkit should
automatically expand the selection to the entire contents of the link
E) something I haven't thought of..

Which one of the above is the right answer?  As I'm relatively new to
WebKit development and have very little experience with the editing
internals, I would greatly appreciate some advice from people with more
experience in this area.

Also, if anybody can try to reproduce the behavior described above in
any of the other ports (especially mac or windows), I'd be very
interested to hear your results.


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



More information about the webkit-unassigned mailing list