Drag and drop is disabled by 3rd party flash website

VERIFIED FIXED in mozilla2.0b11

Status

()

VERIFIED FIXED
8 years ago
8 years ago

People

(Reporter: GeekShadow, Assigned: enndeakin)

Tracking

({regression})

Trunk
mozilla2.0b11
x86
Linux
regression
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(2 attachments)

(Reporter)

Description

8 years ago
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.
(Reporter)

Updated

8 years ago
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Hmm, probably not since it works in 3.6 + Flash.
Keywords: regression, regressionwindow-wanted
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.
How strange. When both web apps are in the same tab, d-n-d works, 
in FF4 and in FF3.6
(Reporter)

Comment 7

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

Comment 8

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

Comment 9

8 years ago
Posted 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.
(Assignee)

Comment 10

8 years ago
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]
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).
Attachment #505096 - Flags: review?(karlt) → review+
Blocks: 331241
(Assignee)

Updated

8 years ago
Attachment #505096 - Flags: approval2.0?
(Assignee)

Comment 13

8 years ago
http://hg.mozilla.org/mozilla-central/rev/32f8623164fb
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED
Assignee: nobody → enndeakin
Keywords: regressionwindow-wanted
Target Milestone: --- → mozilla2.0b10
(Reporter)

Comment 14

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

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