Open
Bug 497494
Opened 15 years ago
Updated 2 years ago
Don't process unrelated events while retrieving data in nsDragService::GetTargetDragData()
Categories
(Core :: Widget: Gtk, defect, P5)
Tracking
()
NEW
Tracking | Status | |
---|---|---|
blocking2.0 | --- | - |
People
(Reporter: karlt, Unassigned)
References
(Blocks 1 open bug)
Details
Currently nsDragService::GetTargetDragData() (for gtk2) runs an event loop until the selection data is received. nsIDragSession clients (including indirect clients) may not expect other events to be processed during read of the numDropItems attribute or during getData(). nsClipBoard uses a special event loop in wait_for_retrieval() to process only the events in the Display's queue that are necessary for retrieving the selection. That code (added in bug 214583) could be shared by GetTargetDragData(). An alternative is to make the DnD APIs asynchronous (bug 322085). That would require changing the WHATWG DataTransfer interface, and maybe the DragEvent interface also. http://www.whatwg.org/specs/web-apps/current-work/multipage/editing.html#datatransfer
Reporter | ||
Comment 1•15 years ago
|
||
I /think/ blocking on selection retrieval (with a timeout) and making it appear synchronous makes sense for a drop event. The drop event came from the user and other user events (the one's that could interact with the drop at least) should probably not be processed until the drop event has been completed. (Currently drop events don't move focus, but perhaps they should just like paste events. If so then a user's typing should probably be applied after the drop event has completed.) In considering dragover events, I wondered whether it might make sense to process other user events while retrieving data for processing the dragover event. If a drop event is subsequently received, then there is no need to complete the processing of the dragover event. However, if the drag-source app was following the XDND protocol (http://newplanetsoftware.com/xdnd/), it wouldn't send the XdndDrop message until it had received the XdndStatus response after the destination has processed the XdndPosition (dragover) message. GTK's XDND implementation of XDND actually sends the XdndDrop without waiting for the XdndStatus, but it doesn't seem right to code for this quirk of implementation. Currently GetTargetDragData() gets confused when called recursively, as shared storage is used.
Reporter | ||
Comment 2•14 years ago
|
||
Since bug 545714 landed, the nested event loops is always being run on the first drag over. One set of STR for bug 497498 is: 1. Run Firefox with NSPR_LOG_MODULES=nsDragService:5,WidgetDrag:5 in the environment. 2. Drag something from another app quickly across the corner of about:blank. 3. Repeat 2 until the log spew continues without drag motion. (I've requested blocking on this bug rather than bug 497498 because I'm guessing this is the easier bug to fix and it would solve more common problems.)
blocking2.0: --- → ?
Comment 3•14 years ago
|
||
Without any symptoms or clear statement of problems that can be caused by this, it's not clear to me that it should block. Can you restate the problem that users or code will experience and renominate?
blocking2.0: ? → -
Reporter | ||
Comment 4•14 years ago
|
||
I'll request blocking on bug 497498 because I think I know how we can fix that one.
Comment 5•5 years ago
|
||
Priority: -- → P5
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•