Windowless plug-in support for X (WMODE)

RESOLVED FIXED in mozilla1.9alpha8

Status

()

Core
Plug-ins
P5
normal
RESOLVED FIXED
15 years ago
7 years ago

People

(Reporter: Braden, Assigned: karlt)

Tracking

({pp})

Trunk
mozilla1.9alpha8
All
Linux
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [PL2:P5] [READ COMMENTS 93 & 106 BEFORE POSTING HERE])

Attachments

(4 attachments, 9 obsolete attachments)

19.16 KB, patch
Details | Diff | Splinter Review
821 bytes, text/html
Details
12.23 KB, patch
Details | Diff | Splinter Review
4.45 KB, text/html
Details
(Reporter)

Description

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

Comment 1

15 years ago
..probably can be done on Linux since it works on Windows, but dunno where to
start. Did 4.x have an implementation?
Summary: Windowless plug-in support → [RFE] Windowless plug-in support for X
(Reporter)

Comment 2

15 years ago
No, it didn't.

Comment 3

15 years ago
setting to future
Assignee: beppe → serge
Priority: -- → P5
Target Milestone: --- → Future
(Reporter)

Comment 4

15 years ago
This is a platform parity issue, and thus not an enhancement.
Severity: enhancement → normal
Keywords: pp
Hardware: PC → All
Summary: [RFE] Windowless plug-in support for X → Windowless plug-in support for X

Updated

15 years ago
Whiteboard: [PL2:P5]

Comment 5

15 years ago
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?
(Reporter)

Comment 6

15 years ago
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.

Comment 7

15 years ago
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.

Comment 8

15 years ago
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.


Comment 9

15 years ago
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. 

Comment 10

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

Comment 11

15 years ago
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.  

Comment 12

15 years ago
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.

Comment 13

15 years ago
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. 

Comment 14

15 years ago
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.

Comment 15

15 years ago
Created attachment 104801 [details] [diff] [review]
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).

Comment 17

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

Comment 18

14 years ago
*** Bug 231557 has been marked as a duplicate of this bug. ***
*** Bug 240781 has been marked as a duplicate of this bug. ***

Comment 20

13 years ago
Created attachment 148794 [details] [diff] [review]
Rough patch based on david's patch

Using unixprinting plugin as testcase.

Comment 21

13 years ago
Created attachment 148795 [details]
test page of this patch

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

Comment 22

13 years ago
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
(Reporter)

Comment 24

13 years ago
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.

Comment 26

13 years ago
Created attachment 169650 [details] [diff] [review]
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.

Comment 27

13 years ago
Created attachment 169652 [details]
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. ***

Comment 33

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

Comment 34

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

Comment 35

12 years ago
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...

Comment 37

12 years ago
I had this working about a year ago ..

Comment 38

11 years 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.
Assignee: srgchrpv → nobody
QA Contact: shrir → plugins

Comment 41

11 years ago
*** Bug 273585 has been marked as a duplicate of this bug. ***
(Reporter)

Comment 42

11 years ago
*** 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. ***

Comment 45

11 years ago
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.

Comment 49

11 years ago
*** 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?
Summary: Windowless plug-in support for X → Windowless plug-in support for X (WMODE)
I see... It was Konqueror 3.5.2 and up. I tested with Konqueror 3.5.5 and WMODE was honored.

Comment 52

11 years ago
*** 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 [details] [diff] [review]
updated to trunk

Updated the patch to trunk. Need to implement event handling and do some testing.
Assignee: nobody → roc
Status: NEW → ASSIGNED

Comment 56

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

Updated

11 years ago
Duplicate of this bug: 370377
Duplicate of this bug: 371294
Duplicate of this bug: 251823

Updated

11 years ago
Duplicate of this bug: 372104
Duplicate of this bug: 374119

Comment 62

10 years ago
Robert, how is the patch coming along?

Updated

10 years ago
Duplicate of this bug: 376818

Updated

10 years ago
Duplicate of this bug: 369948

Comment 65

10 years ago
(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...

Updated

10 years ago
Duplicate of this bug: 377063

Comment 67

10 years ago
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).

Comment 68

10 years ago
Adobe going to fix most known flash visual issues by using XEmbed?

http://blogs.adobe.com/penguin.swf/2007/04/bling.html

Comment 69

10 years ago
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)

Comment 70

10 years ago
(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.

(Assignee)

Comment 71

10 years ago
Created attachment 265192 [details] [diff] [review]
updated to trunk 2007-05-17

(Not working yet)
Attachment #247032 - Attachment is obsolete: true
(Assignee)

Comment 72

10 years ago
Created attachment 266368 [details] [diff] [review]
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 [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.
Assignee: roc → mozbugz
Attachment #265192 - Attachment is obsolete: true
(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.
(Assignee)

Comment 74

10 years ago
Created attachment 267541 [details] [diff] [review]
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).
Attachment #266368 - Attachment is obsolete: true
(Assignee)

Comment 75

10 years ago
Created attachment 267964 [details] [diff] [review]
 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.
Attachment #267541 - Attachment is obsolete: true
(Assignee)

Comment 76

10 years ago
Created attachment 267965 [details] [diff] [review]
windowless mode for diamondx-0.1

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

Updated

10 years ago
Blocks: 258089

Updated

10 years ago
Duplicate of this bug: 384337
(Assignee)

Updated

10 years ago
Depends on: 384845
(Assignee)

Updated

10 years ago
Depends on: 384975
(Assignee)

Updated

10 years ago
Depends on: 384988

Comment 78

10 years ago
Created attachment 270102 [details] [diff] [review]
X11 windowless plugin support 0.2.1

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

Comment 79

10 years ago
Created attachment 270111 [details] [diff] [review]
 X11 windowless plugin support 0.2.2

more fit to the latest trunk because of the checkin of the bug 347743.
Attachment #270102 - Attachment is obsolete: true
(Assignee)

Updated

10 years ago
Blocks: 386144
(Assignee)

Updated

10 years ago
Attachment #104801 - Attachment is obsolete: true
(Assignee)

Comment 80

10 years ago
(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.
(Assignee)

Updated

10 years ago
Attachment #267964 - Attachment is obsolete: true
(Assignee)

Comment 81

10 years ago
Comment on attachment 267965 [details] [diff] [review]
windowless mode for diamondx-0.1

See bug 386144 for an updated version.
Attachment #267965 - Attachment is obsolete: true
(Assignee)

Comment 82

10 years ago
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.
Attachment #270111 - Attachment is obsolete: true
(Assignee)

Updated

10 years ago
Depends on: 386537
(Assignee)

Comment 83

10 years ago
Implementation checked in.
Status: ASSIGNED → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → FIXED
Target Milestone: Future → mozilla1.9beta1

Comment 84

10 years ago
Woohoo! At last :)

Comment 85

10 years ago
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

Comment 86

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

Comment 87

10 years ago
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
> 

Updated

10 years ago
Duplicate of this bug: 389549

Comment 89

10 years ago
(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.
Duplicate of this bug: 389929
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.
Duplicate of this bug: 395598

Comment 96

10 years ago
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.
Duplicate of this bug: 402835

Updated

10 years ago
Duplicate of this bug: 402741

Comment 99

10 years ago
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?
Duplicate of this bug: 404930
(Assignee)

Comment 101

10 years ago
(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.

Comment 102

10 years ago
(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.
Duplicate of this bug: 407129
Duplicate of this bug: 407924

Comment 105

10 years ago
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.

Comment 107

10 years ago
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.
Duplicate of this bug: 407924

Comment 110

10 years ago
(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.

Comment 111

10 years ago
(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.
(Assignee)

Comment 112

10 years ago
(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.
Whiteboard: [PL2:P5] → [PL2:P5] [READ COMMENTS 93 & 106 BEFORE POSTING HERE]
Duplicate of this bug: 410033
Duplicate of this bug: 412156
Duplicate of this bug: 420157

Comment 116

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

Comment 117

9 years ago
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.

Comment 119

9 years ago
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.

Comment 120

9 years ago
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 :-)
(Reporter)

Comment 121

9 years ago
If Adobe does claim such a thing, that ain't it.

Converting a plug-in to XEmbed does not automatically make it windowless.

Comment 122

9 years ago
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.

Comment 124

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

Comment 125

9 years ago
doesn't work here, why should it?

Comment 126

9 years ago
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).

Comment 127

9 years ago
not working with FF 3 pre + Flash 124 :-(

if you have a working FF version please let me know.

Comment 128

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

Comment 129

9 years ago
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.

Comment 130

9 years ago
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?

Comment 131

9 years ago
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

Comment 133

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

Updated

9 years ago
Duplicate of this bug: 435857

Comment 135

9 years ago
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

Comment 137

9 years ago
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?

Comment 139

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

Comment 140

9 years ago
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 :-( 

Comment 141

9 years ago
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.

Comment 142

9 years ago
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.

Comment 143

9 years ago
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.
Duplicate of this bug: 461467
Duplicate of this bug: 462489

Updated

7 years ago
You need to log in before you can comment on or make changes to this bug.