626157 - Drag and drop is disabled by 3rd party flash website

Status: VERIFIED FIXED

(Core :: DOM: Copy & Paste and Drag & Drop, defect)

Description

[Antoine Turmel [:GeekShadow]]

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 http://geekshadow.com/gaming/weaponscolors/ and hit Play button, dragging characters into gray boxes work.
2. now open new tab with http://www.media.pearson.com.au/schools/cw/au_sch_whalley_sf1_1/dnd/9_volcano.html
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.

Comment 1

[Mounir Lamouri (:mounir)]

It's working for me with 3.6 and Gnash.

Comment 2

[Olli Pettay [:smaug][[e-mail]]]

Not working in FF4b10pre + Flash.

I wonder if the problem is actually in Flash implementation.

Comment 3

[Olli Pettay [:smaug][[e-mail]]]

Hmm, probably not since it works in 3.6 + Flash.

Comment 4

[Olli Pettay [:smaug][[e-mail]]]

Regression range would be great. 
I think I'd start searching around the time when bug 130078 was fixed.

Comment 5

[Olli Pettay [:smaug][[e-mail]]]

...which could still mean that the problem is in Flash.

Comment 6

[Olli Pettay [:smaug][[e-mail]]]

Attachment: 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

Comment 7

[Antoine Turmel [:GeekShadow]]

Under Windows XP SP3 32bits with Shockwave Flash (NPSWF32.dll
Version : 10.1.102.64
Shockwave Flash 10.1 r102
it's working fine.

Comment 8

[Antoine Turmel [:GeekShadow]]

On Linux it's not working :
Ubuntu 10.10 (Maverick i686)
and Flash version is : 10.1.102.65ubuntu0.10.10.1

Comment 9

[Neil Deakin]

Attachment: patch

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.

Comment 10

[Neil Deakin]

A regression from plugin widgets at the toplevel?

Comment 11

[Karl Tomlinson (:karlt)]

(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 12

[Karl Tomlinson (:karlt)]

Comment on attachment 505096 [details] [diff] [review]
patch

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).

Comment 13

[Neil Deakin]

http://hg.mozilla.org/mozilla-central/rev/32f8623164fb

Comment 14

[Antoine Turmel [:GeekShadow]]

It's works now :)
Mozilla/5.0 (X11; Linux i686; rv:2.0b10pre) Gecko/20110125 Firefox/4.0b10pre

Thanks !