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.
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
Under Windows XP SP3 32bits with Shockwave Flash (NPSWF32.dll Version : 10.1.102.64 Shockwave Flash 10.1 r102 it's working fine.
On Linux it's not working : Ubuntu 10.10 (Maverick i686) and Flash version is : 10.1.102.65ubuntu0.10.10.1
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?
Attachment #505096 - Flags: review?(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 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+
Attachment #505096 - Flags: approval2.0?
Attachment #505096 - Flags: approval2.0? → approval2.0+
Status: NEW → RESOLVED
Last Resolved: 8 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 !
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.