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)

x86
Linux
defect

Tracking

()

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
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.
Blocks: 497498
Blocks: 507607
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: --- → ?
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: ? → -
I'll request blocking on bug 497498 because I think I know how we can fix that one.
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.