Bug 3957 – java and flash applets and regular html paint collide

• Status: RESOLVED
• Resolution: WONTFIX
• Component: Plug-ins

[Tom]

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.

[Oliver Hunt]

Confirmed in current ToT -- need a reduced test case though

[Kevin]

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]

More info on this:
http://www.dreamflow.nl/archives/technology/000031.html

[Kevin]

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]

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

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

*** Bug 5608 has been marked as a duplicate of this bug. ***

[Joost de Valk (AlthA)]

This is not only true for flash but for other applets, like java applets, as well. Changing subject.

[Matt Pennig]

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]

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]

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

*** Bug 8699 has been marked as a duplicate of this bug. ***

[Lewis Francis]

[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]

All of these issues appear to be fixed in current nightly builds for me.

Looks like this bug can be closed now.

[larsen]

@ #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]

The Bug 18740 I filed is also related to this bug. There are good test cases attached to it.

[Y-H Chen]

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]

I filed a new bug to make it clear that the problem currently appears to be limited to WebKit Gtk.

[Y-H Chen]

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

NPAPI support has been removed from Safari 14 onward and also from WebkitGTK builds. Can this be closed as "RESOLVED WONTFIX"? Thanks!

[Ryosuke Niwa]

Yup, won't fix.