Closed Bug 31012 Opened 25 years ago Closed 24 years ago

linux needs legacy plugin support for 4.x plugins

Categories

(Core Graveyard :: Plug-ins, defect, P3)

Product:
Core Graveyard
Component:
Plug-ins
Platform:
x86
Linux
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: blizzard, Assigned: rusty.lynch)

Details

Attachments

(1 file)

patch to support legacy plugins
81.76 KB, patch
Details | Diff | Splinter Review 
...and lucky for us someone at intel is really bored.  Patch coming.
Here's Randy's readme for the patch:

linux_legacy_patch: This patch adds legacy plugin support for Linux
                    versions of Mozilla.  The following patch was tested
                    on the 2/27/2000 nightly build source.

                    Use 'patch -p1 < linux_legacy_patch` in the mozilla
                    directory to apply the patch.

Known problems:

        - Because of Motif's requirement to be linked before libXt,
          the only way I have been able to run a legacy plugin using
          statically compiled Motif is link the plug-in wrapper with
          Motif (in the correct order.)  Since this would require 
          the person doing the build to have the Motif libraries,
          it's not really a solution.

        - For whatever reason, Macromedia's Flash 4 plugin crashes 
          the browser on the first SetWindow function.  I've been
          trying to get my legal guys to get me the Flash source
          so I could find the hole, but I'm still waiting.  For 
          what it's worth, the open source flash plugin does work
          as good as on my old Netscape browser (which doesn't say
          much)

-----------------------------------------------------------------------------

mozilla/

        * allmakefiles.sh: added reference to new gtkxtbin Makefile

        * Makefile.in: added line to compile gtkxtbin and gtksuperwin
                       libraries (if it's a gtk build) before the 
                       module/plugins/nglsrc directory builds.

mozilla/widget/src/gtkxtbin/

        * Makefile.in, gtkxtbin.c gtkxtbin.h: GtkXtBin widget library

        NOTE: I also have a brief description of this new widget
              at http://206.58.79.35/gtkxtbin/index.html

mozilla/widget/src/gtk/

        * nsAppShell.cpp: just applies some NS_DEBUG code to set the X error
                          handling routines to do harmless printf's.
                          I was having troubles with the open source
                          Flash plugin causing BadWindow errors that
                          would kill the browser. I'm still not sure
                          if the errors were caused by the buggy plugin
                          or a hole in the legacy support.

mozilla/module/plugins/nglsrc/

        * Makefile.in (and Makefile): added gtkxtbin, gtksuperwin, and Xt
                                      to EXTRA_DSO_LDOPTS and also
                                      require gtksuperwin and gtkxtbin
                                      libraries

        * nsPluginsDirUNIX.cpp: explicitly opens Xt with global flags set
                                so the Xt based legacy plugin libraries
                                do not fail to load.

        * nsPluginHostImpl.cpp: implements brain dead file streaming to get
                                be something to work with

        * ns4xPluginInstance.cpp & ns4xPluginInstance.h: actually implements
                                the Linux legacy plugin support

                - The main idea is to use a new gtk widget called GtkXtBin
                  that initializes the Xt environment, attaches a new Xt
                  event loop in the g_main_loop, and creates a new Xt
                  Widget whos X window is a child of a GdkWindow (passed
                  into the gtk_xtbin_new(some_gdkwindow) call.)  
                - ns4xPluginInstance::SetWindow takes care to create a new
                  GtkXtBin widget, allocate and fill out the NPWindow's
                  ws_info structure (with the display pointer set to the
                  new Xt display), and finally set NPWindow's window
                  pointer to the X window of the newly created Xt Widget.

mozilla/layout/base/src/

        * nsPluginViewer.cpp: fixes full page plugin viewing on Linux



Blizzard, you are insane.  Why dont you let motif die a nice and quiet death ?

Hey, I didn't write it.
Ok, I now have the source to Macromedia's Linux Flash plug-in and know
why the Flash plug-in is crashing the browser.  

In SetWindow() the plug-in is trying to set an event handler for window 
resizes.  There is an assumption that one of the widget ansestors (and the 
widget to watch for resizes) is named "form".  The code walks through each of 
the parent widgets looking for the "form" widget, but never considers that 
eventually XtParent(somewidget) will return null, and then dies trying to 
strcmp on a null string.

I have never seen any Netscape plug-in documentation that promised a "form" 
widget.  Is Macromedia's assumption valid?  Are there any other common 
assuptions that the legacy wrapper should consider?
Damned if I know.  I've never lived in 4.x plugin land.  alecf/ramiro, do you
guys know?
Adding pollmann to the cc list since he is rumored to know the plugin code on
4.x.  Can you comment on the last question if you have time?
and amusil...
I don't recall anything about a widget named "form" - my guess is that
Macromedia needed to get access to a top-level widget and found that "form" was
the name of the widget they wanted by probing x.  So yes, the assumption was
valid for 4.x browsers, but, for Mozilla...  :S

I wish I could be of more help here, but I was almost exclusively involved with
maintaining and working on the default plugin for Unix.  The default plugin is
relatively simple in it's requirements compared to other plugins out there, so I
don't know what other assumptions might have been made by legacy plugin
developers.  Perhaps Alex or Andre could speak more about the issues that the
developers contacted them about.

As far as I know from my work in the default plugin, almost all browser related
calls went through the plugin APIs.  I can only remember one case where I had to
go outside them, to get a handle on the top level widget, and that was though:

  FE_GetToplevelWidget();

It was a global function in the 4.x world - though I doubt that's true in the
new world.  On the bright side, the only way I found that call was because I had
access to the source for 4.x which most plugin developers probably did not.

Hope that helps in some way.  :)
So, are you guys waiting on me to reveiw this patch or make comments or
something?  Are you interested in me checking it in?  It sounds like there are
still some problems with the patch since you can't get the flash plugin to work.
Yes, it would be good to get some sort of closure on this fix (go/no-go).

I agree that there is still some work to be done in terms of support of Motif 
plugins and support of Macromedia Flash.  However, what we have with this fix 
get's us much closer to support legacy plugins.  Concerning Motif, we're going 
to have to live with the fact that Motif is not compatible with Mozilla.  There 
are ways for us to support Motif plugins, but none of the possiblities are very 
pretty.  Concerning Flash, it made some assumptions on the window structure and 
window names which are not specified anywhere within the LiveConnect plugin 
SDK.  We've actually manage to get Flash working on Mozilla with this patch by 
commenting out the lines within Flash which makes assumptions on the window 
structure.  At this point, I think the problem with Flash is actually Flash and 
not the fix for legacy plugin support.

Either way, it would be good to get some closure on this patch so that we 
(Intel) can move on and look at other things within Mozilla.  My opinion is 
that it's time to get a Linux version of Mozilla out the door which supports 
legacy plugins so that plugin providers can take a look at any incompatibilies 
their particular plugins might have (e.g. Macromedia Flash).
There is a similar request for Win32 in bug 22996...
Status: NEW → ASSIGNED
Please ignore the spam.  Changing address.
Assignee: blizzard → blizzard
Status: ASSIGNED → NEW
bustage from my reassign
Status: NEW → ASSIGNED
Ok, I finally checked in changes to turn on legacy plug-in support for Linux as
described previously in this bug report.  That is... with an extra tweak so that
the window structure is what the Flash plug-in assumes.  I know the Flash
plug-in shouldn't have been making those window structure assumptions, but since
Flash was my favorite plug-in I couldn't see letting it get shelfed (until a new
XPCom plug-in is developed.)

Also, since Flash does a good job exercising this little hack, it points out any
holes.  Some of these are:
  1. Since I didn't apply the hack to replace Gtk's fatal Xlib error function,
     if a plug-in tries to play with a non-existant XWindow, the browser will
     exit.  This will occur (sometimes) when you try to leave a flash plug-in
     page.
  2. Full screen plug-ins do not work. There was a one liner fix in my previous
     patch, but since mozilla/layout/base/src/nsPluginViewer.cpp had changed
     so much (and since the full screen viewer seems to be in bad shape for
     Linux) it didn't want to confuse the matter.
  3. As mentioned before, and plug-in staticly linked to Motif will take the
     browser down in flames.
Thanks so much rusty!  Good work.

Just a note.  I think that this will leak the Xt structures and context. 
There's no _destroy function for the widget that you've created.
Assignee: blizzard → rusty.lynch
Status: ASSIGNED → NEW
Now that the basic implementation is in, what do we do with this bug.  The Linux
legacy support is far from bug free.   Should this bug be used to capture the
resulting bugs, or should new reports be made and this bug closed out?

We have linux legacy plug-in support.  It's just got a lot of holes.
I'd vote for closing this bug and filing separate bugs for issues as they come 
up.
I agree with waterson.  If there are specific issues open them as seperate bugs.
Closing the bug where any resulting bugs from this fix will result in 
new bugs.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Marking verif. Am logging seperate bugs for issues with legacy plugins on linux.
Status: RESOLVED → VERIFIED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: