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.
Confirmed in current ToT -- need a reduced test case though
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"
More info on this: http://www.dreamflow.nl/archives/technology/000031.html
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?
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
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... ;)
*** Bug 5608 has been marked as a duplicate of this bug. ***
This is not only true for flash but for other applets, like java applets, as well. Changing subject.
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.
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.
(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. ***
[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?
All of these issues appear to be fixed in current nightly builds for me. Looks like this bug can be closed now.
@ #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
The Bug 18740 I filed is also related to this bug. There are good test cases attached to it.
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.
I filed a new bug to make it clear that the problem currently appears to be limited to WebKit Gtk.
(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