Last Comment Bug 137189 - Windowless plug-in support for X (WMODE)
: Windowless plug-in support for X (WMODE)
Status: RESOLVED FIXED
[PL2:P5] [READ COMMENTS 93 & 106 BEFO...
: pp
Product: Core
Classification: Components
Component: Plug-ins (show other bugs)
: Trunk
: All Linux
: P5 normal with 33 votes (vote)
: mozilla1.9alpha8
Assigned To: Karl Tomlinson (:karlt)
:
:
Mentors:
: 189608 215237 231557 240781 251823 273585 292149 297066 307640 348641 351208 354322 359983 360722 362988 369948 370377 371294 372104 374119 376818 377063 384337 389549 389929 395598 402741 402835 404930 407129 407924 410033 412156 420157 435857 461467 462489 (view as bug list)
Depends on: 384845 384975 384988 386537
Blocks: 258089 386144
  Show dependency treegraph
 
Reported: 2002-04-12 14:35 PDT by Braden
Modified: 2010-09-17 20:16 PDT (History)
114 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Rough patch for implementing windowless support on Unix (7.95 KB, patch)
2002-10-31 14:07 PST, David Brittain
no flags Details | Diff | Splinter Review
Rough patch based on david's patch (19.16 KB, patch)
2004-05-18 20:22 PDT, Leon Sha
no flags Details | Diff | Splinter Review
test page of this patch (821 bytes, text/html)
2004-05-18 20:25 PDT, Leon Sha
no flags Details
revised patch against trunk (12.23 KB, patch)
2004-12-27 11:56 PST, Pete Collins (MDG)
no flags Details | Diff | Splinter Review
New Test page using unixprintplugin (4.45 KB, text/html)
2004-12-27 11:59 PST, Pete Collins (MDG)
no flags Details
updated to trunk (26.49 KB, patch)
2006-11-29 20:09 PST, Robert O'Callahan (:roc) (email my personal email if necessary)
no flags Details | Diff | Splinter Review
updated to trunk 2007-05-17 (23.24 KB, patch)
2007-05-17 18:56 PDT, Karl Tomlinson (:karlt)
no flags Details | Diff | Splinter Review
patch using gfxXlibNativeRenderer (41.04 KB, patch)
2007-05-28 03:47 PDT, Karl Tomlinson (:karlt)
no flags Details | Diff | Splinter Review
X11 windowless plugin support 0.1 (55.04 KB, patch)
2007-06-06 23:55 PDT, Karl Tomlinson (:karlt)
no flags Details | Diff | Splinter Review
X11 windowless plugin support 0.2 (58.85 KB, patch)
2007-06-11 07:20 PDT, Karl Tomlinson (:karlt)
no flags Details | Diff | Splinter Review
windowless mode for diamondx-0.1 (31.91 KB, patch)
2007-06-11 07:25 PDT, Karl Tomlinson (:karlt)
no flags Details | Diff | Splinter Review
X11 windowless plugin support 0.2.1 (53.66 KB, patch)
2007-06-27 17:51 PDT, Takanori MATSUURA
no flags Details | Diff | Splinter Review
X11 windowless plugin support 0.2.2 (53.71 KB, patch)
2007-06-27 19:14 PDT, Takanori MATSUURA
no flags Details | Diff | Splinter Review

Description Braden 2002-04-12 14:35:17 PDT
Can windowless plug-in support be made to work with X, or is this a non-starter?
Comment 1 Peter Lubczynski 2002-04-22 17:58:16 PDT
..probably can be done on Linux since it works on Windows, but dunno where to
start. Did 4.x have an implementation?
Comment 2 Braden 2002-04-22 19:19:31 PDT
No, it didn't.
Comment 3 rubydoo123 2002-07-03 11:44:02 PDT
setting to future
Comment 4 Braden 2002-07-10 09:18:25 PDT
This is a platform parity issue, and thus not an enhancement.
Comment 5 rubydoo123 2002-08-05 19:31:08 PDT
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?
Comment 6 Braden 2002-08-05 21:49:39 PDT
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 David Brittain 2002-08-06 01:10:36 PDT
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 serge (gone) 2002-08-06 11:03:11 PDT
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 Ed Millard 2002-10-23 11:30:43 PDT
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 David Brittain 2002-10-23 13:02:52 PDT
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 Ed Millard 2002-10-23 13:39:53 PDT
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 David Brittain 2002-10-25 01:44:02 PDT
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 Ed Millard 2002-10-25 07:57:29 PDT
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 David Brittain 2002-10-25 08:03:17 PDT
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 David Brittain 2002-10-31 14:07:28 PST
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.
Comment 16 Robert O'Callahan (:roc) (email my personal email if necessary) 2003-08-01 13:53:27 PDT
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 Bill Mason 2003-08-06 08:08:51 PDT
*** Bug 215237 has been marked as a duplicate of this bug. ***
Comment 18 Alfonso Martinez 2004-02-21 04:00:18 PST
*** Bug 231557 has been marked as a duplicate of this bug. ***
Comment 19 Boris Zbarsky [:bz] (still a bit busy) 2004-04-17 12:07:05 PDT
*** Bug 240781 has been marked as a duplicate of this bug. ***
Comment 20 Leon Sha 2004-05-18 20:22:44 PDT
Created attachment 148794 [details] [diff] [review]
Rough patch based on david's patch

Using unixprinting plugin as testcase.
Comment 21 Leon Sha 2004-05-18 20:25:03 PDT
Created attachment 148795 [details]
test page of this patch

Using /modules/plugin/samples/unixprinting/libunixprintplugin.so as the plugin.
Comment 22 Vaclav Dvorak 2004-11-27 16:19:54 PST
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.
Comment 23 Doron Rosenberg (IBM) 2004-11-30 11:35:54 PST
Note that on Fedora Core 3 and latest flash, wmode (transparent flash) works -
http://www.macromedia.com/support/flash/ts/documents/wmode.htm
Comment 24 Braden 2004-11-30 12:08:49 PST
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."
Comment 25 Doron Rosenberg (IBM) 2004-11-30 12:52:01 PST
Missed that.  http://www.communitymx.com/content/source/E5141/wmodetrans.htm
indeed doesn't work on linux correctly, my bad.
Comment 26 Pete Collins (MDG) 2004-12-27 11:56:59 PST
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 Pete Collins (MDG) 2004-12-27 11:59:19 PST
Created attachment 169652 [details]
New Test page using unixprintplugin
Comment 28 Robert O'Callahan (:roc) (email my personal email if necessary) 2005-05-30 00:23:46 PDT
I'll have a look at this.
Comment 29 Robert O'Callahan (:roc) (email my personal email if necessary) 2005-06-15 21:34:10 PDT
+                    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.
Comment 30 Robert O'Callahan (:roc) (email my personal email if necessary) 2005-06-15 21:35:00 PDT
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.
Comment 31 Boris Zbarsky [:bz] (still a bit busy) 2005-09-02 14:59:17 PDT
Pete, do you want to take this bug and address roc's comments?
Comment 32 Phil Ringnalda (:philor) 2005-09-09 18:47:45 PDT
*** Bug 307640 has been marked as a duplicate of this bug. ***
Comment 33 José Jeria 2005-10-08 13:57:52 PDT
*** Bug 292149 has been marked as a duplicate of this bug. ***
Comment 34 José Jeria 2005-10-08 14:01:07 PDT
*** Bug 297066 has been marked as a duplicate of this bug. ***
Comment 35 eric.caron 2006-01-10 08:23:47 PST
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.
Comment 36 Boris Zbarsky [:bz] (still a bit busy) 2006-01-10 08:33:45 PST
Someone should just take the patch in this bug, update it to review comments and trunk, and get it checked in...
Comment 37 Pete Collins (MDG) 2006-01-10 08:40:29 PST
I had this working about a year ago ..
Comment 38 changdong.cui 2006-03-21 00:34:47 PST
(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.
Comment 39 Marek Stępień [:marcoos, inactive] 2006-03-29 13:41:30 PST
The KDE guys have recently fixed a similar problem in KHTML. 
See http://bugs.kde.org/show_bug.cgi?id=31121 .

Comment 40 Robert O'Callahan (:roc) (email my personal email if necessary) 2006-03-29 14:31:34 PST
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.
Comment 41 José Jeria 2006-06-04 16:00:45 PDT
*** Bug 273585 has been marked as a duplicate of this bug. ***
Comment 42 Braden 2006-06-04 17:16:57 PDT
*** Bug 189608 has been marked as a duplicate of this bug. ***
Comment 43 Marek Stępień [:marcoos, inactive] 2006-07-21 03:23:15 PDT
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/
Comment 44 Marek Stępień [:marcoos, inactive] 2006-09-10 18:19:28 PDT
*** Bug 351208 has been marked as a duplicate of this bug. ***
Comment 45 Marcelo 2006-09-16 14:14:12 PDT
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.
Comment 46 Robert O'Callahan (:roc) (email my personal email if necessary) 2006-09-16 14:28:53 PDT
I know how they solved it in Konqueror and I've got a similar fix in bug 345669.
Comment 47 :Gavin Sharp [email: gavin@gavinsharp.com] 2006-09-17 14:15:07 PDT
(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?
Comment 48 Robert O'Callahan (:roc) (email my personal email if necessary) 2006-09-17 21:30:50 PDT
Yes.
Comment 49 José Jeria 2006-09-26 12:22:08 PDT
*** Bug 354322 has been marked as a duplicate of this bug. ***
Comment 50 Brian 'netdragon' Bober 2006-10-24 18:07:06 PDT
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?
Comment 51 Brian 'netdragon' Bober 2006-10-24 19:19:24 PDT
I see... It was Konqueror 3.5.2 and up. I tested with Konqueror 3.5.5 and WMODE was honored.
Comment 52 José Jeria 2006-10-30 11:44:41 PST
*** Bug 348641 has been marked as a duplicate of this bug. ***
Comment 53 Phil Ringnalda (:philor) 2006-11-09 00:10:07 PST
*** Bug 359983 has been marked as a duplicate of this bug. ***
Comment 54 Phil Ringnalda (:philor) 2006-11-14 15:29:43 PST
*** Bug 360722 has been marked as a duplicate of this bug. ***
Comment 55 Robert O'Callahan (:roc) (email my personal email if necessary) 2006-11-29 20:09:49 PST
Created attachment 247032 [details] [diff] [review]
updated to trunk

Updated the patch to trunk. Need to implement event handling and do some testing.
Comment 56 José Jeria 2006-12-06 11:29:36 PST
*** Bug 362988 has been marked as a duplicate of this bug. ***
Comment 57 Brian Polidoro 2007-02-14 09:11:26 PST
*** Bug 370377 has been marked as a duplicate of this bug. ***
Comment 58 Phil Ringnalda (:philor) 2007-02-22 13:31:34 PST
*** Bug 371294 has been marked as a duplicate of this bug. ***
Comment 59 Phil Ringnalda (:philor) 2007-02-26 23:02:11 PST
*** Bug 251823 has been marked as a duplicate of this bug. ***
Comment 60 Brian Polidoro 2007-02-28 09:38:24 PST
*** Bug 372104 has been marked as a duplicate of this bug. ***
Comment 61 Phil Ringnalda (:philor) 2007-03-15 15:18:40 PDT
*** Bug 374119 has been marked as a duplicate of this bug. ***
Comment 62 pascal 2007-03-16 05:11:29 PDT
Robert, how is the patch coming along?
Comment 63 Kevin Brosnan 2007-04-07 15:48:30 PDT
*** Bug 376818 has been marked as a duplicate of this bug. ***
Comment 64 Kevin Brosnan 2007-04-07 17:15:48 PDT
*** Bug 369948 has been marked as a duplicate of this bug. ***
Comment 65 Tom 2007-04-07 17:44:04 PDT
(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...
Comment 66 Kevin Brosnan 2007-04-10 12:30:04 PDT
*** Bug 377063 has been marked as a duplicate of this bug. ***
Comment 67 DarkMageZ 2007-04-15 16:48:36 PDT
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 Zbigniew Luszpinski 2007-04-20 14:45:07 PDT
Adobe going to fix most known flash visual issues by using XEmbed?

http://blogs.adobe.com/penguin.swf/2007/04/bling.html
Comment 69 walter sheets 2007-04-20 15:39:25 PDT
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 Tinic Uro 2007-04-20 17:30:16 PDT
(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.

Comment 71 Karl Tomlinson (:karlt) 2007-05-17 18:56:07 PDT
Created attachment 265192 [details] [diff] [review]
updated to trunk 2007-05-17

(Not working yet)
Comment 72 Karl Tomlinson (:karlt) 2007-05-28 03:47:01 PDT
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.
Comment 73 carglue a t ya hoo do tcom 2007-05-30 09:52:25 PDT
(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.
Comment 74 Karl Tomlinson (:karlt) 2007-06-06 23:55:47 PDT
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).
Comment 75 Karl Tomlinson (:karlt) 2007-06-11 07:20:44 PDT
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.
Comment 76 Karl Tomlinson (:karlt) 2007-06-11 07:25:45 PDT
Created attachment 267965 [details] [diff] [review]
windowless mode for diamondx-0.1

(diamondx-0.1 is available from http://multimedia.cx/diamondx/)
Comment 77 Adam Guthrie 2007-06-13 22:48:10 PDT
*** Bug 384337 has been marked as a duplicate of this bug. ***
Comment 78 Takanori MATSUURA 2007-06-27 17:51:44 PDT
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 Takanori MATSUURA 2007-06-27 19:14:51 PDT
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.
Comment 80 Karl Tomlinson (:karlt) 2007-06-28 02:41:59 PDT
(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 81 Karl Tomlinson (:karlt) 2007-06-28 02:47:38 PDT
Comment on attachment 267965 [details] [diff] [review]
windowless mode for diamondx-0.1

See bug 386144 for an updated version.
Comment 82 Karl Tomlinson (:karlt) 2007-06-28 03:00:31 PDT
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.
Comment 83 Karl Tomlinson (:karlt) 2007-07-02 22:36:56 PDT
Implementation checked in.
Comment 84 Julian Sikorski 2007-07-03 01:39:17 PDT
Woohoo! At last :)
Comment 85 Jeroen van Agt 2007-07-10 02:02:03 PDT
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 Julian Sikorski 2007-07-10 02:51:17 PDT
The transparency needs support on the flash plugin side as well. IIRC it's not there yet.
Comment 87 Leon Sha 2007-07-10 02:57:19 PDT
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
> 

Comment 88 Adam Guthrie 2007-07-25 10:09:42 PDT
*** Bug 389549 has been marked as a duplicate of this bug. ***
Comment 89 Alberto Gonzalez 2007-07-25 10:17:47 PDT
(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.

Comment 90 Robert O'Callahan (:roc) (email my personal email if necessary) 2007-07-25 11:34:25 PDT
Try drawing text (with no background color) over a Flash object in KHTML.
Comment 91 Marek Stępień [:marcoos, inactive] 2007-07-28 13:18:56 PDT
*** Bug 389929 has been marked as a duplicate of this bug. ***
Comment 92 Fabio Pugliese Ornellas 2007-07-28 16:31:08 PDT
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.
Comment 93 Robert O'Callahan (:roc) (email my personal email if necessary) 2007-07-29 15:39:36 PDT
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.
Comment 94 Fabio Pugliese Ornellas 2007-07-29 16:43:09 PDT
OK, thank you for your attention.
Comment 95 Matthias Versen [:Matti] 2007-09-09 19:46:36 PDT
*** Bug 395598 has been marked as a duplicate of this bug. ***
Comment 96 Chihwa Kim 2007-09-25 11:56:14 PDT
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.
Comment 97 Matthias Versen [:Matti] 2007-11-07 06:00:46 PST
*** Bug 402835 has been marked as a duplicate of this bug. ***
Comment 98 Brian Polidoro 2007-11-07 06:28:43 PST
*** Bug 402741 has been marked as a duplicate of this bug. ***
Comment 99 suriro 2007-11-23 12:46:29 PST
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?
Comment 100 Matthias Versen [:Matti] 2007-11-24 09:47:02 PST
*** Bug 404930 has been marked as a duplicate of this bug. ***
Comment 101 Karl Tomlinson (:karlt) 2007-11-25 11:56:56 PST
(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 jan klopper 2007-11-25 12:58:35 PST
(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.
Comment 103 Matthias Versen [:Matti] 2007-12-06 03:35:46 PST
*** Bug 407129 has been marked as a duplicate of this bug. ***
Comment 104 Matthias Versen [:Matti] 2007-12-11 10:08:57 PST
*** Bug 407924 has been marked as a duplicate of this bug. ***
Comment 105 Robert Smol 2007-12-11 12:39:28 PST
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
Comment 106 Martijn Wargers [:mwargers] (not working for Mozilla) 2007-12-11 13:01:59 PST
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 Michael Cronenworth 2007-12-11 13:08:15 PST
Am I missing something? Firefox 3 beta 1 doesn't appear to be fixed. Flash 9.0 r115 is still above HTML elements.
Comment 108 Martijn Wargers [:mwargers] (not working for Mozilla) 2007-12-11 13:13:35 PST
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.
Comment 109 Matthias Versen [:Matti] 2007-12-12 12:01:56 PST
*** Bug 407924 has been marked as a duplicate of this bug. ***
Comment 110 Foteos Macrides 2007-12-20 10:26:43 PST
(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 Henrique 2007-12-21 05:28:10 PST
(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.
Comment 112 Karl Tomlinson (:karlt) 2007-12-26 14:31:02 PST
(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.
Comment 113 Matthias Versen [:Matti] 2007-12-28 09:18:55 PST
*** Bug 410033 has been marked as a duplicate of this bug. ***
Comment 114 Reed Loden [:reed] (use needinfo?) 2008-01-13 01:09:31 PST
*** Bug 412156 has been marked as a duplicate of this bug. ***
Comment 115 Matthias Versen [:Matti] 2008-02-28 12:43:27 PST
*** Bug 420157 has been marked as a duplicate of this bug. ***
Comment 116 Samuel LB 2008-04-14 07:42:18 PDT
This bug has also been reported in Adobe's bug tracker:
https://bugs.adobe.com/jira/browse/FP-80
Comment 117 Nadav Kavalerchik 2008-04-16 13:51:21 PDT
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 ?
Comment 118 Martijn Wargers [:mwargers] (not working for Mozilla) 2008-04-16 14:01:45 PDT
Nadav, see comment 93.
Comment 119 Kevin Newman 2008-04-16 14:13:12 PDT
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 Nadav Kavalerchik 2008-04-16 14:35:17 PDT
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 :-)
Comment 121 Braden 2008-04-16 14:37:30 PDT
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 Kevin Newman 2008-04-16 15:35:11 PDT
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. :-)
Comment 123 Robert O'Callahan (:roc) (email my personal email if necessary) 2008-04-16 16:17:39 PDT
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 Tom Chiverton 2008-04-17 13:06:49 PDT
Could you please retest with the latest Player (v9.0.124) ?
Comment 125 Jan Niklas Hasse 2008-04-17 13:14:40 PDT
doesn't work here, why should it?
Comment 126 Kevin Newman 2008-04-17 13:39:53 PDT
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 Nadav Kavalerchik 2008-04-17 13:42:55 PDT
not working with FF 3 pre + Flash 124 :-(

if you have a working FF version please let me know.
Comment 128 Jan Niklas Hasse 2008-04-17 13:48:49 PDT
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 Nadav Kavalerchik 2008-04-17 14:05:09 PDT
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 Jan Niklas Hasse 2008-04-17 14:23:58 PDT
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 Kevin Newman 2008-04-17 15:23:04 PDT
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.
Comment 132 Karl Tomlinson (:karlt) 2008-04-22 16:06:38 PDT
swfdec are making some progress with this:

http://lists.freedesktop.org/archives/swfdec/2008-April/001426.html
Comment 133 Bjorn 2008-05-15 22:57:38 PDT
Please lobby in Gnash to have this plug-in fixed as well:
https://savannah.gnu.org/bugs/?group=gnash
Comment 134 Kevin Brosnan 2008-05-27 05:16:11 PDT
*** Bug 435857 has been marked as a duplicate of this bug. ***
Comment 135 Bjorn 2008-06-23 11:41:14 PDT
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!
Comment 136 Matthias Versen [:Matti] 2008-07-03 13:48:08 PDT
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 walter sheets 2008-07-03 16:18:39 PDT
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.
Comment 138 Martijn Wargers [:mwargers] (not working for Mozilla) 2008-07-05 13:06:34 PDT
Walter, perhaps file a new bug for that?
Comment 139 Stefan Thomas 2008-07-06 00:16:36 PDT
No slowness here. Everything is perfect, menus display instantly, no problem.
Comment 140 Nadav Kavalerchik 2008-07-06 06:47:24 PDT
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 walter sheets 2008-07-06 07:40:35 PDT
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 Pat Suwalski 2008-08-14 12:42:29 PDT
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 walter sheets 2008-08-14 16:56:48 PDT
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.
Comment 144 Bill Gianopoulos [:WG9s] 2009-03-02 04:26:39 PST
*** Bug 461467 has been marked as a duplicate of this bug. ***
Comment 145 Bill Gianopoulos [:WG9s] 2009-03-02 04:27:57 PST
*** Bug 462489 has been marked as a duplicate of this bug. ***

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