Build: 2002-09-05-05 Platform: OS X 10.2 Expected Results: Broken icon should appear where plugin content would be rendered. What I got: Plugin content is missing and no visual feedback like a broken icon is displayed. Steps to reproduce: 1) Go to url which requires shockwave player plugin 2) After page loads, no broken icon is displayed where plugin content would be rendered.
Maybe I should have summarized this bug as "Chimera needs a default plugin" since this probably why it's working in Mozilla.
Chris, could you drop the default plugin from a Moz/NS build into the chimera plugins folder and let me know if that fixes the problem... if so, then building/installing the default plugin would be the quickest solution.
After coping the default plugin to Chimera's plugin directory, the app now does two different things: 1) When loading url, a second window opens that goes to the shockwave player plugin download page 2) Broken plugin icon appears where the plugin content would have appeared Tested with the 2002-09-06-05 NB under 10.2.
*** Bug 167184 has been marked as a duplicate of this bug. ***
I also notice one thing, In the window that shows the default plugin saying "click here after installing the plugin" , If I RELOAD that page...boom browser crashes. Petersen, could u pls check ?thx!
I'm not able to crash Chimera after reloading the URL multiple times. I just get the results mentioned in Comment #3. Tested under 2002-09-06-05 NB and 10.2.
I talked to bryner about this and he thinks it will be a fairly straightforward task to get the default plugin built and added to the package.
Unfortunately, it's not as easy as I'd hoped. I got the plugin to build with gcc, and even included the resource fork, but Chimera isn't recognizing it (it's not appearing in about:plugins). One thing I noticed is that this plugin uses 'main' as the entry point; is that only supported for CFM plugins?
I tried copying over the osx default plugin..reloaded 'about:plugins' and saw it listed in there.
brian gone---->peterl yeah, Mach-O loads CFM plugins okay because of the function pointer fix-up. It could be doing it unconditionally. Can you attach the patch you used to get it building?
Created attachment 104228 [details] [diff] [review] Patch to get Macho default plugin building I checked a DefaultPlugin.pbproj into the tree already. With this patch, you can build a Macho version of the default plugin. Note that I changed the name of the main entrypoint for Macho, from 'main' to 'mainMachO'. This is so that the host app can tell what format they're dealing with -- there should be a way to get this from NSPR. Note that you'll need the changes in bug 176830 to make this work.
It seems that the plugin should, instead, be wrapping the host CFM-style function pointers in glue such that they are callable from Macho (code in NSPR does this).
Comment on attachment 104228 [details] [diff] [review] Patch to get Macho default plugin building sr=beard
Created attachment 104303 [details] [diff] [review] Patch to make the Macho default plugin use CFM-style TVectors This patch allows the Default plugin to be built as Macho, while remaining compatible with the plugin API CFM-style entry points. The code creates TVector->function pointer glue for Netscape functions, and returns fp->TV glue for plugin functions. The allocated glue is freed on shutdown. The only other change, here: + if (wErr == dirNFErr) + wErr = FSMakeFSSpec(fsTheApp.vRefNum, fsTheApp.parID, "\p:Plugins:Default Plug-in Data", &sDataFileSpec); allows the plugin to work if intstalled in a "plugins" or "Plugins" directory, rather than "Plug-ins". (HFS is case insensitive). The name of the main entrypoint was not changed (but its return type had to change to keep gcc happy).
Created attachment 104438 [details] [diff] [review] Updated patch, uses static data for glue, rather than mallocing.
Comment on attachment 104438 [details] [diff] [review] Updated patch, uses static data for glue, rather than mallocing. Consider making TTVtoFPGlue and TFPtoTVGlue classes, with constructors that do the a appropriate initialization. This would ensure at most once intialization of the glue objects. Your code now reinitializes them if the plugin is reloaded. Of course, this might be the right thing to do for safety sake.
Created attachment 104548 [details] [diff] [review] Final patch: static glue, and uses CFPreferences on OS X to store seen MIME types This is my final answer. The patch does runtime detection for running on OS X, and on that platform uses CFPreferences to store a list of seen plugin types in the host applications's domain (under the "DefaultPluginSeenTypes" key).
Comment on attachment 104548 [details] [diff] [review] Final patch: static glue, and uses CFPreferences on OS X to store seen MIME types r=sdagley
Changes have been checked in. Marking Fixed. Bug 179863 has been filed for the trunk. Note that the Macho default plugin won't show up until we fix the build machine.
Hmmm. I'm not seeing the default plugin listed in Chimera's package (Contents- MacOS - plugins). Nor does the default plugin show up in about:plugins. Tested under 2002-11-22-04 NB under 10.2 and 10.1.5.
Build changes done to get the Default plugin in there.
Verifying default plugin is now included in 2002-11-27-04 NB. Default plugin now displays plugin icon when required plugin is not found. Removed QT, Flash and Real plugins and verified this is the case. With pages that included the pluginspace attribute, the default plugin redirected to the specified url.