[MASTER] Adobe Flash does not support WMODE (Flash content always rendered on top of web pages)

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

Created attachment 104801
Rough patch for implementing windowless support on Unix

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

Created attachment 148794
Rough patch based on david's patch

Using unixprinting plugin as testcase.

Created attachment 148795
test page of this patch

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.

Created attachment 169650
revised patch against trunk

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.

Created attachment 169652
New Test page using unixprintplugin

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

Created attachment 247032
updated to trunk

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

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

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

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

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

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

Robert, how is the patch coming along?

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

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

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

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

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.

Created attachment 265192
updated to trunk 2007-05-17

(Not working yet)

Created attachment 266368
patch using gfxXlibNativeRenderer

This patch provides windowless drawing support and the modified unixprinting test plugin works as expected with the dhtml and background in attachment 169652. (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.

Created attachment 267541
X11 windowless plugin support 0.1

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

Created attachment 267964
 X11 windowless plugin support 0.2

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.

Created attachment 267965
windowless mode for diamondx-0.1

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

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

Created attachment 270102
X11 windowless plugin support 0.2.1

fit to the latest trunk.
Some part of the attachment 267694 is applied by bug 384965 and bug 380984.

Created attachment 270111
 X11 windowless plugin support 0.2.2

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
windowless mode for diamondx-0.1

See bug 386144 for an updated version.

Comment on attachment 270111
 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
>

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

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

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

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.

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

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.

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

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

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?

*** Bug 404930 has been marked as a duplicate of this 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.

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

*** Bug 407924 has been marked as a duplicate of this 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.

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

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

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

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

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

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 435857 has been marked as a duplicate of this bug. ***

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.