Can windowless plug-in support be made to work with X, or is this a non-starter?

..probably can be done on Linux since it works on Windows, but dunno where to start. Did 4.x have an implementation?

No, it didn't.

setting to future

This is a platform parity issue, and thus not an enhancement.

Braden: I would like to open this bug up to a more focused issue and thus change the OS to ALL - as well as change the summary to state "Need windowless plug-in support for Flash" would that be acceptable to you?

beppe: I think "Windowless plug-in support for X" pretty accurately describes the problem here. The problem is by no means unique to Flash. It sounds to me that if we did what you describe, this would be a duplicated of bug 44322. This bug exists because bug 44322 was resolved without addressing this issue for X. If it is preferred that a single bug be used to track this issue on all platforms--and especially if there exist problems with windowless plug-ins on Windows and/or Mac that would be motivation for broadening the scope of this bug--I suggest that it is appropriate to reopen bug 44322 and mark this one as a duplicate of it.

I think bug 44322 should stay closed, it was about reproducing the NS 4.x functionality. The title of this bug seems to describe pretty well what this bug is about. Has anyone verified that windowless plugins don't work under X, I'm sure they don't work, but a test case would be useful. I'd probably have a look at this if I didn't have to go to the effort of learning how to implement the plugin side of a windowless plugin under X. I wouldn't expect a fix to be too difficult, there is a lot of #ifdef'd code in the windowless code that passes windows specific messages - I would guess that we just need to work out what the appropriate action would be for X in each of these cases.

there is no windowless plug-in support on X, and never been, even in 4.x world, therefore I'm not aware of any test cases, anyway I wouldn't change anything in this bug, it is valid generic X bug, not only flash relatead.

If someone can give me the hooks to do an XCopyArea from the browser window to the Flash buffer I will implement this. I have all the framework in place, it seems to work, I just need to get the browser pixels at the start of our redraw cycle. Note that hooks to do an XCopyArea from an offscreen X image holding the browser window image would be preferable though I imagine one of these doesn't exist.

Hi Ed, I had just started looking at getting this working. Can you attach a patch for the work that you have done?

All the work I've done is in our plugin, so there is no patch that will be of much use to you. I've basicly just implemented the Windowless code we are using in our Mac player up to the point that where I need X11 hooks to get an XImage from the browser.

I was looking at implementing this in a similar way to windows. So, that an XEvent will get passed through HandleEvent. I was thinking of using an Expose event and passing the drawable through in the Window parameter. Would that work for you? I'll try to put together a patch this weekend.

If the drawable is an off screen XImage it will work. If the drawable is a window the flicker will be unacceptable because there will be a long period while the browser background is on screen. I'm told Windowless mode isn't supported on Mac Classic for this same reason, flicker. There are also needs to be a protocol on who ultimately puts the off screen image on screen. I'm assuming it will be the plugin but I'm not sure what the pro's and con's are.

The drawable will be an offscreen image, which will only be valid for use for the length of the call to HandleEvent. The browser will be passing its current backbuffer through to the plugin, to allow the plugin to render directly into it.

The patch does not work in its current state, I have attached it so I don't lose what I've done. It is also not very polished, e.g. I am sure there is a better way of doing the GTK specific stuff without #ifdefing it everywhere. The aim at the moment is to get it working and worry about tidying it up later! On the plugin side I have implemented HandleEvent as follows: uint16 nsPluginInstance::HandleEvent(void* aEvent) { NPEvent * event = (NPEvent *)aEvent; switch (event->type) { case GraphicsExpose: { XGraphicsExposeEvent* exevent = (XGraphicsExposeEvent*)event; //GC gc = XCreateGC(exevent->display, exevent->drawable, 0, NULL); //mWindow is stored from the call to SetWindow if(!mWindow) return 1; GC gc = (GC)(mWindow->window); if (!gc) return 1; XDrawRectangle(exevent->display, exevent->drawable, gc, x, y, w, h); However it crashes inside the call to XDrawRectangle, which I guess means that there is something wrong with the drawable. I'm not really an expert on Xlib so if anyone has any suggestions I'll be grateful.

I wish I'd known about this bug! There is a fairly easy way to do this. When we call Paint() on the plugin frame, it should synthesize an event and pass it to the plugin, along with a drawable obtained from the nsIRenderingContext parameter. This drawable will be an *offscreen* pixmap (because the view manager paints frames onto an offscreen area for double-buffering purposes).

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

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

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

Using unixprinting plugin as testcase.

Using /modules/plugin/samples/unixprinting/libunixprintplugin.so as the plugin.

Is there anything I can do to push this forward? Does the patch need testing, for example? Is there a reason there is no review request for it? Thank you.

Note that on Fedora Core 3 and latest flash, wmode (transparent flash) works - http://www.macromedia.com/support/flash/ts/documents/wmode.htm

Are you sure? "Note: Because of restrictions in this form, the layer is simulated. Viewing the source of this page will not reflect the method accurately."

Missed that. http://www.communitymx.com/content/source/E5141/wmodetrans.htm indeed doesn't work on linux correctly, my bad.

One of the things I am unsure of is how I am obtaining the drawable: nsObjectFrame.cpp exposeEvent.drawable = (Drawable)win->GetNativeData(NS_NATIVE_WIDGET); So maybe others who have worked on this patch or know layout internals better can collaborate. I'll post a revised test case next.

I'll have a look at this.

+ exposeEvent.drawable = (Drawable)win->GetNativeData(NS_NATIVE_WIDGET); You want NS_NATIVE_WINDOW so that this can work in GTK1. Other than that, this looks pretty good on the painting side. But the event handling is missing. You need something like this: http://lxr.mozilla.org/mozilla/source/layout/generic/nsObjectFrame.cpp#3883 Fix that and I think we're close to having something we can check in ... need testing from the Macromedia folks though, really.

It would be great if we can land this for 1.8/FF 1.1. I'll be happy to review it when the code is ready.

Pete, do you want to take this bug and address roc's comments?

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

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

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

Does anyone know who can be contacted regarding this long-standing issue? Perhaps somebody from another X project, maybe a Gnome/KDE developer? Maybe compiling a list of websites where this becomes an issue would show the severity of this problem.

Someone should just take the patch in this bug, update it to review comments and trunk, and get it checked in...

I had this working about a year ago ..

(In reply to comment #29) > + exposeEvent.drawable = > (Drawable)win->GetNativeData(NS_NATIVE_WIDGET); > > You want NS_NATIVE_WINDOW so that this can work in GTK1. > > Other than that, this looks pretty good on the painting side. But the event > handling is missing. You need something like this: > > http://lxr.mozilla.org/mozilla/source/layout/generic/nsObjectFrame.cpp#3883 > > Fix that and I think we're close to having something we can check in ... need > testing from the Macromedia folks though, really. a field "window" in the "NPWindow" Structure, such as In Windows Platform, just explained as a hdc. can we add a variable in the class "ns4xPluginInstance" to hold the Drawable. if it is windowless. then we can retrieve it. if it is windowed ,we just omit it.

The KDE guys have recently fixed a similar problem in KHTML. See http://bugs.kde.org/show_bug.cgi?id=31121 .

That is really a different problem. As far as I can tell, what they've done there doesn't allow stuff like drawing text over a plugin.

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

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

Well, Google Video puts HTML divs over Flash on Linux and it somehow magically works in Linux Firefox. I analyzed their code - it seems they put an iframe between the <embed> and the <div>, set the iframe's display to 'none' via CSS and then to 'block' via JS (setting it in a stylesheet does not work). More here: http://marcoos.wordpress.com/2006/07/21/html-div-above-a-flash-animation-on-linux-its-possible/ A working proof-of-concept: http://beta.aviary.pl/marcoos/flashlinux/

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

Don't know if this information is usefull, but pages with menus that are incorrectly shown under flash objects in Firefox are correctly displayed in KDE's Konqueror using the very same flash plug-in. Some examples: http://www.asus.com/index.aspx http://www.bovespa.com.br http://www.natura.com.br Maybe it's worth to contact KDE developers to get some information about how did they solve the problem in Konqueror.

I know how they solved it in Konqueror and I've got a similar fix in bug 345669.

(In reply to comment #46) > I know how they solved it in Konqueror and I've got a similar fix in bug > 345669. Did you mean bug 339548?

Yes.

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

I have Konqueror 3.5.1 and Flash 9 and I'm still seeing the issue with the Asus link. Are you sure Konqueror fixed it?

I see... It was Konqueror 3.5.2 and up. I tested with Konqueror 3.5.5 and WMODE was honored.

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

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

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

Updated the patch to trunk. Need to implement event handling and do some testing.

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

Robert, how is the patch coming along?

(In reply to comment #43) > Well, Google Video puts HTML divs over Flash on Linux and it somehow magically > works in Linux Firefox. > > I analyzed their code - it seems they put an iframe between the <embed> and the > <div>, set the iframe's display to 'none' via CSS and then to 'block' via JS > (setting it in a stylesheet does not work). > > More here: > http://marcoos.wordpress.com/2006/07/21/html-div-above-a-flash-animation-on-linux-its-possible/ > > A working proof-of-concept: > http://beta.aviary.pl/marcoos/flashlinux/ > The flash, the proof-of-concept works fine for me, but it still does not fix the problem on other websites. Even "Adobe.com" still gets the same problem. i would have to say asking thousands of sites to implement some sort of fix for the problem would be asking too much. They wont do it, trust me. Implementing a fix in Firefox would be the ideal solution. It looks like someone is working on the patch, I am willing to test if you have something...

hey, is there any chance of a revised version of the patch for the current trunk? the current version doesn't apply cleanly and my noobie attempts to make it apply end up making the build result in a build error (doesn't error without my hacked up version of the patch).

Adobe going to fix most known flash visual issues by using XEmbed? http://blogs.adobe.com/penguin.swf/2007/04/bling.html

I just tried the plugin from your adobe.com link and it works fine on trunk. I hope it has something to do with this bug :o)

(In reply to comment #69) > I just tried the plugin from your adobe.com link and it works fine on trunk. > That means you did not understand the problem. The diamond is supposed to be alpha composited on top of the HTML page. Right now the background always stays plain white. If it would be working there would be no white. No browser on Linux or BSD supports this right now. The patch attached to this bug is trying to address this, but right now it segfaults the test plugin and no events are dispatched. This needs to be fixed before we can make any progress.

(Not working yet)

This patch provides windowless drawing support and the modified unixprinting test plugin works as expected with the dhtml and background in attachment 169652 [details]. (It draws a centered rectangle and also the dirty rectangle outline for testing.) The DiamondX plugin needs some modification to work with this windowless API. The major changes from the previous patch are: * Use gfxXlibNativeRenderer to get a Drawable. (The rendering context doesn't have a gdk widget for a Drawable.) * Using an XGraphicsExposeEvent to describe the Drawable, display, and the dirty rectangle. * Removed the XGraphicsExposeEvent that described the port rectangle relative to the containing window origin. If necessary, this is probably better done with an XConfigureEvent. But AFAIK it is only used on Windows for interpreting mouse events. X11 mouse events have root window coordinates so I don't think the information will be needed. * The NPSetWindowCallbackStruct ws_info field of the window in the SetWindow call contains the visual to use, but currently none of the other fields contain useful information. The display for the Document window could be useful as the display for the Drawable need not be the same. Is anything else needed here? (http://developer.mozilla.org/en/docs/NPSetWindowCallbackStruct) Note that the window field of the window in the SetWindow call is not set as the Drawable is provided by the XGraphicsExposeEvent. Perhaps there is something else this window field can be used for? Document or containing window (one of which can be obtained through nsPluginInstancePeerVariable_NetscapeWindow)? Still to do: * Events * More testing / optimization. * ? printing Set NSPR_LOG_MODULES=nsObjectFrame:4,Plugin:9,PluginNPP:9,PluginNPN:9 for debug output.

(In reply to comment #72) > Created an attachment (id=266368) [details] > patch using gfxXlibNativeRenderer It should be stated that the above patch will not work for Moz 1.8.x branches. The gfxXlibNativeRenderer source files it updates are only available in SeaMonkey. Is it possible to mangle any of the other patches to work against the current FIREFOX_2_0_0_3_RELEASE sources? I've tried using the patches from comments #71 and #26 and neither will patch cleanly.

This patch includes the previous (drawing) patch and adds event dispatching. It should be very usable now. The mouse events have x and y relative to the plugin rectangle origin. This seemed the most useful information to me, but is not the same as what is provided on Windows. (I think on Windows the mouse events are relative to the containing window.) As the XEvents sent to the plugin are synthesized and there is not a native window corresponding to the plugin rectangle, some of the fields of the XEvents are not set to their normal Xserver values. e.g. Key events don't have a position. However the information should be complete enough. (It is enough for the DiamondX plugin, but this plugin needs some modification for windowless support). The mouse events do not yet have the root window coordinates set. Are these needed? It seems that Mozilla doesn't send mouse scroll events to (windowless) plugins. Not sure if this is intentional or not. This patch also activates the code for the NPNVnetscapeWindow GetValue call, which returns the containing native window (not the document window as is sometimes returned on Windows).

Modifications include: * Setting window->ws_info->colormap. * Making the NPNVnetscapeWindow GetValue call return an XID instead of a GdkWindow*. * Sanitizing the dirty rect in the GraphicsExpose event so that it does not extend beyond the plugin port rect.

(diamondx-0.1 is available from http://multimedia.cx/diamondx/)

fit to the latest trunk. Some part of the attachment 267694 [details] [diff] [review] is applied by bug 384965 and bug 380984.

more fit to the latest trunk because of the checkin of the bug 347743.

(In reply to comment #73) > Is it possible to mangle any of the other patches to work against the current > FIREFOX_2_0_0_3_RELEASE sources? I've tried using the patches from comments > #71 and #26 and neither will patch cleanly. I'm not familiar enough with the 1.8 branch to know the best way to obtain the drawable. You'd need something that was a mix of the patches in comment #20 and/or #26 and the latest patches.

Comment on attachment 267965 [details] [diff] [review] windowless mode for diamondx-0.1 See bug 386144 for an updated version.

Comment on attachment 270111 [details] [diff] [review] X11 windowless plugin support 0.2.2 (In reply to comment #79) > more fit to the latest trunk because of the checkin of the bug 347743. Thanks for resolving the conflict, but please use the latest patches in the other bugs in the dependency tree: https://bugzilla.mozilla.org/showdependencytree.cgi?id=137189&hide_resolved=1 The updated implementation is awaiting review in bug 384845, bug 384975, and bug 384988. The unixprinting example plugin is available (unchanged) in bug 386144. Thanks to everyone who contributed to this.

Implementation checked in.

Woohoo! At last :)

Tested with Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a7pre) Gecko/2007070905 Minefield/3.0a7pre. It seems that transparent flash still does not work

The transparency needs support on the flash plugin side as well. IIRC it's not there yet.

This feature needs plug-in's support. Flash player does not support this feature yet. (In reply to comment #85) > Tested with Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a7pre) > Gecko/2007070905 Minefield/3.0a7pre. It seems that transparent flash still does > not work >

(In reply to comment #87) > This feature needs plug-in's support. > Flash player does not support this feature yet. I don't know where the problem is, if in flash plugin or Firefox, but in Konqueror transparent flash works fine, so it must be possible to fix. Thanks.

Try drawing text (with no background color) over a Flash object in KHTML.

This bug has been on market for quite some time, and those of us who use FF under Linux suffer a lot with it. I know now it is Adobe´s responsibility to fix this, however, since Flash is a must have plugin nowadays, would it not be possible to make a (dirty) fix on the code on FF to workaround it temporarily? Konqueror seems to have done it, so in theory, FF can do it also. I can note use some sites the way it is now, it is terrible... I´ve already contacted Adobe on this, I think all of us must do the same to make to pressure them (since FF folks blame them). Until Adobe fix it, I (and all Linux + FF users) surely would benefit a lot from this code hack (if it is possible). Thank you.

Adobe wants to fix it. They had received a lot of user feedback and in fact were pressuring us to fix our side (which we have done). So don't annoy them please. What KHTML does is a partial solution. It's not going to happen for 1.9 although we will be able to do it after that.

OK, thank you for your attention.

Please release bug fixed version of FireFox ASAP. Still, there is no known workaround to avoid this problem on Linux. And, we've been waiting for more than five years.

Menu on the left of http://www.yapikredi.com.tr/tr-TR/bireysel_bankacilik/main.aspx is almost invisible, whereas it displays OK on windows with a blueish light background. Is this the same bug?

(In reply to comment #99) > Menu on the left of > http://www.yapikredi.com.tr/tr-TR/bireysel_bankacilik/main.aspx is almost > invisible, whereas it displays OK on windows with a blueish light background. > Is this the same bug? I can't see any problems with that page on Linux here, but I think it is a different issue. It would be best to file a separate bug with some screenshots.

(In reply to comment #101) > (In reply to comment #99) > > Menu on the left of > > http://www.yapikredi.com.tr/tr-TR/bireysel_bankacilik/main.aspx is almost > > invisible, whereas it displays OK on windows with a blueish light background. > > Is this the same bug? > > I can't see any problems with that page on Linux here, but I think it is a > different issue. It would be best to file a separate bug with some > screenshots. > It is indeed the same bug, but manivested trough a lack of transparancy of the plugin window. The flash image seems to be black in color, where on windows and mac this black would be transparent and thus allow the blue of the lower half of the menu to shine trough. A quick fix for the webmaster is to select the same color blue as the background color of his flash movie instead of the black he's currently using. Nothing new here, so no need for a new bug.

Hello, may I politely ask about the status of this bug? It seems as resolved/fixed however I still see Duplicate reports coming in (that means users are still suffering from this bug right?). If this is still pending, can someone quickly describe current status? Last reasonable update is from July. Thank you

It's fixed on trunk, which means the fix will be in Firefox 3. The fix is not on branch, which means the fix is not in Firefox 2. And I heard something about Adobe needing to update their plugin to make use of the new windowless plug-in support on Linux, so it might not be there yet, to be able to see.

Am I missing something? Firefox 3 beta 1 doesn't appear to be fixed. Flash 9.0 r115 is still above HTML elements.

Lie I said in comment 106, Adobe needs to update their plugin to be able to make use of this new feature. Also note comment 93. Please read previous comments in this bug, it will likely answer any questions you might have.

(In reply to comment #108) > Lie I said in comment 106, Adobe needs to update their plugin to be able to > make use of this new feature. > Also note comment 93. > Please read previous comments in this bug, it will likely answer any questions > you might have. Upgrades of the Adobe Flash plug-in have occurred after this bug was marked as RESOLVED FIXED, so perhaps the question should be asked more explicitly as whether the appropriate communication between the Firefox and Adobe Flash developers about this matter also has occurred.

(In reply to comment #110) > > Upgrades of the Adobe Flash plug-in have occurred after this bug was marked as > RESOLVED FIXED, so perhaps the question should be asked more explicitly as > whether the appropriate communication between the Firefox and Adobe Flash > developers about this matter also has occurred. > Excellent point. BTW, this bug/feature is 5 years old, I'm glad it's being fixed and congratulate the mozilla team. You have no idea how much harm this bug has done.

(In reply to comment #110) > Upgrades of the Adobe Flash plug-in have occurred after this bug was marked as > RESOLVED FIXED, so perhaps the question should be asked more explicitly as > whether the appropriate communication between the Firefox and Adobe Flash > developers about this matter also has occurred. See comment #93. Windowless support in Flash may require significant changes to the plug-in, and I know Adobe are working on this.

This bug has also been reported in Adobe's bug tracker: https://bugs.adobe.com/jira/browse/FP-80

i am using FF 3 pre with Flash 115 and i do not see transparency on several sites i use. do you have a site that is using transparency i can check it ? what versions of FF and Flash should i use to get transparency working ?

Nadav, see comment 93.

I don't see it mentioned here, but adobe claims that this is fixed on their end: http://blogs.adobe.com/penguin.swf/2007/12/flash_player_9_update_3_final.html "Improvement over the string of beta releases: This new XEmbed-enabled plugin should work with Opera now." The XEmbed part being the important bit.

please, i read comment 93 :-) i just want to confirm (in some way) that i have a FF version that this issue is solved from the FF perspective. i have XEmbed installed on FF 3 pre and i do not see it working do you have a FF version i can confirm this issue is solved for ? i opened https://bugs.adobe.com/jira/browse/FP-80 and i just saw... "Flash plugin has to be updated to make use of this functionality." (they probably thought i was referring to FF 2.x) so i guess that they have to fix something on their part it all started... when i hoped this was fixed when i read : http://blogs.adobe.com/penguin.swf/2007/12/flash_player_9_update_3_final.html which does not work in opera (9.5 latest snapshot) :-( thanks :-)

If Adobe does claim such a thing, that ain't it. Converting a plug-in to XEmbed does not automatically make it windowless.

My only concern is that, as I've been following this here and on the blogs for a while, it seems like both sides (Mozilla and Adobe) think that their parts are finished (and have presumably stopped working on the problem). See comment #106 for possible source of confusion. I'll point out that it is NOT working yet, just to be sure. :-)

As far as I know, Adobe has not released anything that supports windowless mode on X, nor have they claimed to. Until they do, the problem is in their court.

Could you please retest with the latest Player (v9.0.124) ?

doesn't work here, why should it?

Not working here either, with Compiz on or off. Ubuntu 7.1 x86, and Ubuntu 8 AMD64 (with mozplugger - which is probably a whole different thing).

not working with FF 3 pre + Flash 124 :-( if you have a working FF version please let me know.

Nadav, FF 3 has got windowless plug-in support, it's the right adobe flash plug-in version we have to wait for.

Jan, how can i test that ? especially to show Adobe developers that FF is ready and that it is a Player issue. it seems (to me) that they are waiting for FF to fix something for some reason.

As said in #93, Adobe is already working on this. It's not that easy, so it will take some time. They just need to open this bug report to know that it has been fixed in FF ;) What make you believe that they are waiting for FF to fix it?

I think the misunderstanding is that in this post: http://blogs.adobe.com/penguin.swf/2007/04/bling.html They introduce the XEmbed addition to the flash player, and released a test case, claiming that it will lead to possible wmode transparency in the Flash player. That set up the expectation then future posts about XEmbed seemed to be talking about this feature. If you read it carefully, they merely say that it could lead to fixed wmode support, not that it would. So I think maybe some of us have just had the wrong idea.

swfdec are making some progress with this: http://lists.freedesktop.org/archives/swfdec/2008-April/001426.html

Please lobby in Gnash to have this plug-in fixed as well: https://savannah.gnu.org/bugs/?group=gnash

Bug report for gnash: https://savannah.gnu.org/bugs/?23435 Please vote (on the gnash site) to have this fixed. This bug affects both gnash and the official flash plug-in, and it would be great if it was fixed in the free version first!

Adobe release a new beta Version of flash 10 at 02 July and the feature list contains : Linux WMODE — new with 7/2/08 build

I just tried it with trunk and it actually works, even if it's agonizingly slow and CPU intensive. http://finance.yahoo.com/echarts?s=^DJI uses flash heavily and a good example of how the new flash works with linux. The dropdown menus (e.g. COMPARE) used to drop down behind the chart and so were invisible. Now they're visible but you wait 15 seconds or so for them to appear while chewing CPU cycles like crazy. Well, at least it works, sort of.

Walter, perhaps file a new bug for that?

No slowness here. Everything is perfect, menus display instantly, no problem.

just in case not every one on this thread read the adobe bug reports for bug number: FP-80 [http://bugs.adobe.com/jira/browse/FP-80] i am not sure if the phenomena (visual flickering and slowness) related to the flash player 10b2 is entirly the responsibility of adobe's flash player ? maybe it's got some issues with firefox or the graphic controller ? (os drivers or propriatry drivers ?) anyways, it is not solved yet ! although there is some great progress :-) here is the last remark i wrote there: just updated FP to 10.0.0 d525 and re-check all the sites i have issues with transparency using FF 3 and opera 9.51 on debian sid (updated) and fedora9 (updated). in general: FF3 on fedora (with intel open source video driver) crashes almost every time i get into a site that uses wmode with flash so i had to go back to FP10b1. on debin sid (with ati M7500 open source video driver) it did not crash the browsers but was not so usable too :-( i tried to disable and enable hardware acceleration with no help. on debian sid machine i got the transparency working on the test site : http://www.communitymx.com/content/source/E5141/wmodetrans.htm works fine on FF3 and OPERA951 :-) my wishlist site :-( [http://www.galim.org.il/fields/holidays.html] it looks like it is working but the entire site "flashs" and flickers (not in a good way) and is not usable. thou, transparency seems to work ! http://www.fox.com/house/ - transparency seems to work but the entire site flickers :-( youtube - sound hangs and video does not play :-(

In my case the problem is the opensource nv driver has no accelerated graphics and so the cpu does all the work. When I switch to the proprietary driver from nVidia the slowness goes away, although there are still some minor rendering bugs. Still, it's a major step forward.

Interestingly, the Acer Aspire One manages to do all this with Firefox2.0.0.14 and Flash9r124. Unfortunately, Linpus' source is nowhere to be found. But their libflashplayer.so is definitely unmodified.

Pat, have you tried the yahoo.com link in my comment #137 ? The dropdown menus on that page drop down *behind* the chart and are unreadable with any Flash but 10beta. At least for me.