RESOLVED WONTFIX 3957
java and flash applets and regular html paint collide
https://bugs.webkit.org/show_bug.cgi?id=3957
Summary java and flash applets and regular html paint collide
Tom
Reported 2005-07-11 20:52:00 PDT
If a dhtml menu drops down over a flash component, and you mouseover the portion of the dhtml menu that overlaps the flash component, their are paint issues that occur. Toyota.com is a current example. mouse over the products or about us menu, and then mouse over the dropdown menu.
Attachments
Test Case for 3957 (2.70 KB, application/zip)
2006-02-17 15:29 PST, Matt Pennig
no flags
Oliver Hunt
Comment 1 2005-07-21 17:27:52 PDT
Confirmed in current ToT -- need a reduced test case though
Kevin
Comment 2 2005-08-11 10:02:37 PDT
Two more sites that show this behavior: http://www.pga.com/pgachampionship/2005/ http://mse.mcview.cjb.net/ The second site is mostly dummy content for my site, so it should be farily "clean"
Wes Hooper
Comment 3 2005-08-15 09:36:21 PDT
Kevin
Comment 4 2005-08-16 12:12:09 PDT
This is a simple site that is basically a mneu and flash: http://www.duoh.com/csstutorials/flazindex/index3.html Does it need to be simpler than that?
Barrie Robinson
Comment 5 2005-08-21 09:53:30 PDT
http://new.emotus.com/ If you click on the orange arrow and then the top menu item, it will bring the DIV layers across the page. I have added a solid blue Flash file so that you can see the issue. I fully tested the overlays thinking that something as simple as a CSS text style change on mouseover would be fully supported. The only way around this is to have no text style change, something I am not keen on for accessibility reasons. Do you think this could be a supported feature in Safari 2.1? It is a bug that has been around since 1.1 after all. Having tried to find a work around for a few weeks I can tell you there are a lot of people struggling with this bug. Thanks
Eric Seidel (no email)
Comment 6 2006-02-17 14:51:05 PST
Flash paints outside of the normal mechanisms. I bet if you specify: <param name="wmode" value="transparent" /> in your object tag where you're including flash, this problem will go away. Then again, you can always use svg... ;)
Joost de Valk (AlthA)
Comment 7 2006-02-17 15:25:09 PST
*** Bug 5608 has been marked as a duplicate of this bug. ***
Joost de Valk (AlthA)
Comment 8 2006-02-17 15:26:54 PST
This is not only true for flash but for other applets, like java applets, as well. Changing subject.
Matt Pennig
Comment 9 2006-02-17 15:29:12 PST
Created attachment 6577 [details] Test Case for 3957 It appears that whenever the following occur above a flash module (a) text is selected, (b) the style of an element changes the effect is this: Any portion of any element overlapping the flash module will disappear until the flash module redraws. The length of this flicker is dependent upon the frame rate of the flash module (currently at 1 fps). One thing of special note is that when hovering over the link, the redraw region of the link does not disappear. I think that this is because of the redraw involved in changing the style of the link to its hover state.
Justin Haygood
Comment 10 2006-04-06 12:21:12 PDT
This is a well-known problem with all browsers on all platforms :). By default, all plugins draw directly to the screen with the alloted space given to them. You need to get them into 'windowless' mode, where it paints to the browser, which is required for z-index layering to work. I don't think this is a bug in WebKit.
Matt Pennig
Comment 11 2006-04-06 16:38:06 PDT
(In reply to comment #10) > This is a well-known problem with all browsers on all platforms :). > > By default, all plugins draw directly to the screen with the alloted space > given to them. You need to get them into 'windowless' mode, where it paints to > the browser, which is required for z-index layering to work. > > I don't think this is a bug in WebKit. > It is indeed a bug. If you reference the test case I uploaded, the wmode attribute on the embed tag is set to opaque, which means flash will draw its contents windowless. Also, if you were to view the same test case in another agent (such as Mozilla or IE), you would not see the errant behavior described.
mitz
Comment 12 2006-05-03 07:06:34 PDT
*** Bug 8699 has been marked as a duplicate of this bug. ***
Lewis Francis
Comment 13 2006-05-03 08:40:40 PDT
[Replicating comments from Bug 8699] The new Adobe/Macromedia site just went with shtml menu drops over a Flash interactive -- as this is a highly trafficked site, may I suggest inclusion in the Safari Compatibility Hit List?
Alexey Proskuryakov
Comment 14 2007-03-31 13:26:09 PDT
All of these issues appear to be fixed in current nightly builds for me. Looks like this bug can be closed now.
larsen
Comment 15 2007-04-18 09:16:35 PDT
@ #14 I’m sorry, but I think there are some issues left, so that this bug is not fully fixed yet. While meanwhile the example page lost it’s function of beeing an example, there is another one: http://www.adobe.com/ Yes, right: with the actual WebKit build (r20914) there is no flickering, as it occurs in Safari 2.04. But e.g. the contextual menu of a link on a layer over a Flash movie sports the Flash contextual menu(!), instead of the right one. On another of your example pages even the cursor changes from pointer to arrow when hovering over links above the flash movie: http://www.duoh.com/csstutorials/flazindex/index3.html (In this site the is no z-index set for the navigation and/or it’s items, but even with a higher z-index set, the cursor changes to arrow) Both cases seem to indicate to me, that the Flash movie is not really behind the hovered layer, i guess … _____________ See also Bug #10111, where I posted pretty the same Comment
Joshua
Comment 16 2008-05-15 04:13:30 PDT
The Bug 18740 I filed is also related to this bug. There are good test cases attached to it.
Y-H Chen
Comment 17 2009-12-25 19:37:32 PST
I am experiencing this problem in Midori 0.2.0 on a Fedora 11 system; the problem appears to be with Webkit GTK; the problem has been observed to occur with GtkLauncher but not Chromium. Please see the link below for comments and screenshots http://www.twotoasts.de/bugs/index.php?do=details&task_id=662&project=2&opened=417 Let me know if you'd like further information.
Y-H Chen
Comment 18 2010-01-04 21:47:52 PST
I filed a new bug to make it clear that the problem currently appears to be limited to WebKit Gtk.
Y-H Chen
Comment 19 2010-04-15 11:58:44 PDT
(In reply to comment #18) > I filed a new bug to make it clear that the problem currently appears to be > limited to WebKit Gtk. That report is here: https://bugs.webkit.org/show_bug.cgi?id=33174
Ahmad Saleem
Comment 20 2022-06-22 16:39:56 PDT
NPAPI support has been removed from Safari 14 onward and also from WebkitGTK builds. Can this be closed as "RESOLVED WONTFIX"? Thanks!
Ryosuke Niwa
Comment 21 2022-06-22 22:18:12 PDT
Yup, won't fix.
Note You need to log in before you can comment on or make changes to this bug.