Closed Bug 626157 Opened 10 years ago Closed 10 years ago

Drag and drop is disabled by 3rd party flash website


(Core :: DOM: Drag & Drop, defect)

Not set





(Reporter: GeekShadow, Assigned: enndeakin)




(Keywords: regression)


(2 files)

User-Agent:       Mozilla/5.0 (X11; Linux i686; rv:2.0b10pre) Gecko/20110115 Firefox/4.0b10pre
Build Identifier: 2011-01-15

A 3rd flash website can disable HTML5 drag and drop on other website.

Reproducible: Always

Steps to Reproduce:
1. go to and hit Play button, dragging characters into gray boxes work.
2. now open new tab with
3. return to the first webpage, and try to drag an drop characters into gray boxes
Actual Results:  
it's not working anymore

Expected Results:  
it should work independently from the flash website

Closing the flash website tab, make the drag and drop work again.
Version: unspecified → Trunk
It's working for me with 3.6 and Gnash.
Not working in FF4b10pre + Flash.

I wonder if the problem is actually in Flash implementation.
Ever confirmed: true
Hmm, probably not since it works in 3.6 + Flash.
Regression range would be great. 
I think I'd start searching around the time when bug 130078 was fixed.
...which could still mean that the problem is in Flash.
Attached file a testcase which works
How strange. When both web apps are in the same tab, d-n-d works, 
in FF4 and in FF3.6
Under Windows XP SP3 32bits with Shockwave Flash (NPSWF32.dll
Version :
Shockwave Flash 10.1 r102
it's working fine.
On Linux it's not working :
Ubuntu 10.10 (Maverick i686)
and Flash version is :
Attached patch patchSplinter Review
nsWindow::get_inner_gdk_window is returning the wrong GdkWindow

This patch makes it work (as I copied it from other calls to gdk_window_peek_children) , but I don't know enough to know whether this is correct.
A regression from plugin widgets at the toplevel?
(In reply to comment #10)
> A regression from plugin widgets at the toplevel?

Sounds likely.

Previously each tab had it's own window, which was hidden when the tab was inactive.  Now all windows are "visible" even though the plugin windows are clipped out.
Comment on attachment 505096 [details] [diff] [review]

Yes, this is good.

GTK associates drag signals with GtkWidgets, but nsWindows are based on GdkWindows, and there are several GdkWindows in the one GtkWidget here.
So this function maps from GtkWidget to GdkWindow, but should only consider the GdkWindows that belong the GtkWidget receiving the drag signal.  As all Gecko nsWindows/GdkWindows belong to the same GtkWidget, it is sufficient to check that the GdkWindow has an nsWindow (as in this patch).
Attachment #505096 - Flags: review?(karlt) → review+
Blocks: 331241
Attachment #505096 - Flags: approval2.0?
Closed: 10 years ago
Resolution: --- → FIXED
Assignee: nobody → enndeakin
Target Milestone: --- → mozilla2.0b10
It's works now :)
Mozilla/5.0 (X11; Linux i686; rv:2.0b10pre) Gecko/20110125 Firefox/4.0b10pre

Thanks !
Target Milestone: mozilla2.0b10 → mozilla2.0b11
You need to log in before you can comment on or make changes to this bug.