Bug 3957

Summary: java and flash applets and regular html paint collide
Product: WebKit Reporter: Tom <opendarwin>
Component: Plug-insAssignee: Nobody <webkit-unassigned>
Status: RESOLVED WONTFIX    
Severity: Major CC: admin, ahmad.saleem792, ap, bugs-webkit, ghulands, larsen, lewis, matt, matthew, myaverageorange, rniwa
Priority: P2    
Version: 420+   
Hardware: Mac   
OS: OS X 10.4   
URL: http://www.dreamflow.nl/archives/technology/000031.html
Attachments:
Description Flags
Test Case for 3957 none

Description Tom 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.
Comment 1 Oliver Hunt 2005-07-21 17:27:52 PDT
Confirmed in current ToT -- need a reduced test case though
Comment 2 Kevin 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"
Comment 3 Wes Hooper 2005-08-15 09:36:21 PDT
More info on this:
http://www.dreamflow.nl/archives/technology/000031.html
Comment 4 Kevin 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?
Comment 5 Barrie Robinson 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
Comment 6 Eric Seidel (no email) 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... ;)
Comment 7 Joost de Valk (AlthA) 2006-02-17 15:25:09 PST
*** Bug 5608 has been marked as a duplicate of this bug. ***
Comment 8 Joost de Valk (AlthA) 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.
Comment 9 Matt Pennig 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.
Comment 10 Justin Haygood 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.
Comment 11 Matt Pennig 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. 
Comment 12 mitz 2006-05-03 07:06:34 PDT
*** Bug 8699 has been marked as a duplicate of this bug. ***
Comment 13 Lewis Francis 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?
Comment 14 Alexey Proskuryakov 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.
Comment 15 larsen 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
Comment 16 Joshua 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.
Comment 17 Y-H Chen 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.
Comment 18 Y-H Chen 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.
Comment 19 Y-H Chen 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
Comment 20 Ahmad Saleem 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!
Comment 21 Ryosuke Niwa 2022-06-22 22:18:12 PDT
Yup, won't fix.