WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
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
Details
View All
Add attachment
proposed patch, testcase, etc.
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
More info on this:
http://www.dreamflow.nl/archives/technology/000031.html
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.
Top of Page
Format For Printing
XML
Clone This Bug