595789 - HTML5 Accessing event.dataTransfer in dragenter event handler breaks drag drop

Status: RESOLVED WORKSFORME

(Core :: Widget: Gtk, defect)

Description

[noel gordon]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US) AppleWebKit/534.3 (KHTML, like Gecko) Chrome/6.0.472.55 Safari/534.3
Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.9) Gecko/20100825 Ubuntu/10.04 (lucid) Firefox/3.6.9

If event.dataTranfer is accessed/read in a dragenter event handler on linux,
spurious drag events are generated, drag events continue to be delivered to
the browser client area, even if the mouse leaves the client area, or drops
data on the client area.
 

Reproducible: Always

Steps to Reproduce:
1. Start firefox from a terminal window.
2. Load the attached test file.
3. Drag drop a desktop file in the drop.
Actual Results:  
The data does not drop, dragover events are continuously sent to the test
page.  The message below appears in the terminal window on Ubuntu Lucid
x86_64 repeatedly ...

(firefox-bin:7427): Gtk-CRITICAL **: gtk_drag_get_data: assertion `GTK_IS_WIDGET (widget)' failed

Comment 1

[noel gordon]

Attachment: test case

Comment 2

[noel gordon]

Attachment: test case without the js alert this time ;)

test case without the js alert this time ;)

Comment 3

[Karl Tomlinson (:karlt)]

Thanks for the test case.
I think this will be mostly fixed in bug 497498, which is scheduled for Firefox 4 (but not fixed yet).  I'll check when fixing that bug.

Comment 4

[Christopher Blizzard (:blizzard)]

Are you sure that can be fixed?  This might be a fundamental sync API vs. async impl (on linux) issue?

Comment 5

[Karl Tomlinson (:karlt)]

(In reply to comment #4)
> Are you sure that can be fixed?  This might be a fundamental sync API vs. async
> impl (on linux) issue?

There are fundamental sync vs. async issues here, yes.
Bug 497498 comment 2 should be quite doable, and I expect that'll make a big difference.  If that's not good enough, we may need bug 497494.

Comment 6

[jpvincent]

I have the same bug on Minefied 4.0b5pre on Windows Seven but in the dragover event : 

"on", being a cross-browser method to attach a listener to an event, 'dropthere' being a DIV ID :

on('dropthere', 'dragover', function(e) {
	e.dataTransfer.dropEffect = 'copy';
});

if I comment that line or if I set it to 'move' (the default value, according to MDN), the 'drop' event is fired appropriately. In this state, it never fires the 'drop' event

FF4 is the only browser to behave this way, so it must be a bug (OK on IE6-9, Safari and Chrome, FF3.6, all tested on windows and MacOS)

Comment 7

[Karl Tomlinson (:karlt)]

jpvincent: it sounds like that deserves it's own bug report.  The WINNT code is quite different from the GTK code, so that's not likely to get fixed in this bug.

Comment 8

[jpvincent]

you're right, I opened bug #610378

Comment 9

[Karl Tomlinson (:karlt)]

Noel, there have been some improvements to the Linux Drag'n'Drop code.
The testcase mostly works for me now, so you may like to try a Firefox 4 from
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-central/

There still seems to be an issue where dragleave is sometimes not the last event when leaving (without dropping), which may be due to bug 497498.

Comment 10

[noel gordon]

Grabbed Firefox 4.0b11pre (2011-01-30) x86_64 Ubuntu/10.04 (Lucid).  No spurious drag events or messages in the console, dropping mostly works for me too, thanks.

Noted the dragleave issue: move the drag out of the content area *very slowly*, on the left in the testcase for example, and you'll always see the dragleave --   move the drag out *real fast* and you won't :(

Second issue: stopPropagation() no longer prevents Firefox navigating after a drop event.

Comment 11

[Karl Tomlinson (:karlt)]

(In reply to comment #10)
Thanks for the feedback, Noel.

> Second issue: stopPropagation() no longer prevents Firefox navigating after a
> drop event.

I noticed the testcase was using that but wasn't aware that it was effective in earlier versions.

Noel, is there a reason to use stopPropagation() instead of preventDefault()?

Neil, do you know whether we have a history of preventing default here in response to stopPropagation()?  Should we continue to do that for the sake of backward compatibility?

Comment 12

[Karl Tomlinson (:karlt)]

That sounds like bug 616902, so probably best to comment there.

Comment 13

[Neil Deakin]

(In reply to comment #11)
> Noel, is there a reason to use stopPropagation() instead of preventDefault()?
> 
> Neil, do you know whether we have a history of preventing default here in
> response to stopPropagation()?  Should we continue to do that for the sake of
> backward compatibility?

That was a bug in earlier versions.

Comment 14

[Karl Tomlinson (:karlt)]

(In reply to Karl Tomlinson (:karlt) from comment #9)
> There still seems to be an issue where dragleave is sometimes not the last
> event when leaving (without dropping), which may be due to bug 497498.

Bug 497498 is now fixed.  I'm no longer reproducing in builds without the fix so maybe that was resolved in Bug 481737 or elsewhere.

Anyway, this seems to be working as intended now.