Closed Bug 31012 Opened 25 years ago Closed 25 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: 25 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: