[Webkit-unassigned] [Bug 66469] New: window.getSelection().rangeCount does not update during a drag and drop

[bugzilla-daemon at webkit.org]

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

           Summary: window.getSelection().rangeCount does not update
                    during a drag and drop
           Product: WebKit
           Version: 528+ (Nightly build)
          Platform: Macintosh Intel
               URL: http://www.deadmarshes.com/webkit/selection.html
        OS/Version: Mac OS X 10.7
            Status: UNCONFIRMED
          Severity: Normal
          Priority: P2
         Component: JavaScriptCore
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: richard at deadmarshes.com


If you visit the attached URL, you'll see a reduced test for what I'm describing here.

I've been working on a WYSIWYG editor.  In this editor, I have a component that reveals a photo library and provides an interface to drag and drop items from that library into the WYSIWYG document.  These components are designed for one another and presently exist within the same browser window.

This works well up to a point.  Where this falls apart is where I want to expand and abstract the functionality to allow drag and drop from a separate, unrelated components.  One of those being a file managing component, for example.  This file managing component places markup on the clipboard containing all of the relevant data I need to know about, the path to a document, the title of a document, and so on.  But it also includes data that I don't need in a WYSIWYG, things like the MIME type and file size.  These are things that are also worthless to the user.

What I'd like to do is to be able to allow the file management side to have its own drag and drop component as it now exists, with all of that extra meta data, but in this separate WYSIWYG application, find a way to intercept the drop and manipulate the markup on the clipboard before the drop occurs, transforming what presently exists there into a simple link upon drop, i.e., <a href='/path/to/document'>Title</a>.

What I find in my attempt to achieve this goal is that a drop event cannot be intercepted unless you cancel the default action of the drag and drop.  Well, in this case, I mostly want the default action.  That is to say, when you drag an item onto the WYSIWYG, as you drag that item, the blinking text cursor follows the mouse pointer and when you drop, the contents of the clipboard are inserted at the point the blinking text cursor presently resides.  What I don't want about the default scenario is the contents of the clipboard as-is, I want to be able to examine and transform the content of the clipboard before that content is inserted.  However, if I attempt to intercept drop, I become responsible for the whole thing, and I find that a drop cannot be detected unless the default action is canceled.

Since that's the case, I attempted to sidestep the system clipboard as an experiment.  In this scenario, what I've attempted to do, is to set the clipboard content provided to the system to null.  Then allow the default drag and drop to take place, but when a drop occurs, insert null at the blinking cursor.  But as the drag portion takes place, I attempt to track the movement of the blinking cursor in the document.  I'm able to do this in other scenarios via window.getSelection(), and with the text cursor position specifically, "getRangeAt(0)".  This works for me in every case, clicking, selecting something.   Where it does not work is during a drag and drop, making even a sideways hack  to achieve my goal improbable, since it is not possible to track the movement of the text cursor.

Furthermore, I find there is an additional inconsistency with regards to the contenteditable region, which won't provide a selection via windows.getSelection() until it has been focused.  The "won't provide a selection via window.getSelection()" I found already documented in a different bug, but I did not see a bug reported that talks about attempting to access window.getSelection() as a drag is taking place over an editable element, which is not possible regardless of whether or not the editable node has been focused.

Finally, I'd love to see the original problem that led me down this path addressed in some way; that is to say, I'd love to see an API emerge that allows you to intercept the content of a drop without having to cancel the default action.

It's also worth noting that the approach laid out by my test case did not work in Chrome.  In that browser, when I set the clipboard to null in "e.dataTransfer.setData('text/html', '');", the "dragover" event did not subsequently fire, so that browser essentially ignored the entire drag and drop action when that occurred.  I did no further cross-browser testing, since my desired goal could not be achieved in Webkit.

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