Closed Bug 45697 Opened 25 years ago Closed 25 years ago

[PIDEV] on Mac, nspl file type should be recognized as an XPCOM component

Categories

(Core :: XPCOM, defect, P1)

Product:
Core
Component:
XPCOM
Platform:
x86
Windows NT
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: ekrock, Assigned: bnesse)

Details

(Keywords: shockwave, Whiteboard: [rtm++])

Attachments

(2 files)

possible fix
789 bytes, patch
Details | Diff | Splinter Review
Fixes for bug 45697
1.37 KB, patch
Details | Diff | Splinter Review
One of the goals of the Mozilla Plug-in API is to make possible the creation of a single, upgraded plug-in binary that will install and run in both Mozilla-based browsers (such as Mozilla and N6) and in older browsers (such as Navigator 4 and IE). We believe this is already possible on Win32 and Linux. However, there is currently a Mac-specific issue blocking this on the Mac. Currently, if you put an nspl file in the XPCOM bin/components directory, it's not recognized. It's desirable to have a single file creator type. The solution is that on the Mac, the nspl file type should be recognized as an XPCOM component. The plug-in developers cc'd on this report can provide more details/explanation if necessary. Assigning to Scott Collins per waterson. Adding [PIDEV] to Summary to flag plug-in API completion bugs that are blocking plug-in developers in general (as opposed to the developer of a specific plug-in).
Emphatically nominating for nsbeta3 as a "correctness and completeness" blocking bug. Without fixing this, plug-in developers will be unable to release a single binary on the Mac that supports both Mozilla and legacy browsers. This would force them to do dual distribution of separate binaries whether they wished to or not.
Keywords: nsbeta3
Status: NEW → ASSIGNED
Adding realplayer keyword as fixing this issue is reported to be a blocker for them. Nick--please add whatever details you're comfortable discussing in public to this bug report.
Keywords: realplayer
Changing QA contact from leger to shrir.
QA Contact: leger → shrir
RealPlayer plugin is creator MOSS and file type NSPL. It appears that it expects a creator of MOZZ. It would be nice if it supported either the creator MOSS or MOZZ, as well as the NSPL file type. Thanks.
Hmmm, this one seems to have slipped through the cracks. I recommend either a plug-in person or a mac person or someone who is both to fix this. The mac work, I'm sure, is just changing four characters somewhere or adding a another test with '||' ... the question is, do old plugins just run out-of-the-box? Or is extra information required. I'm happy to type the four characters, but a plugin- savvy person really needs to tell me that this works. Emailing av@netscape.com for this information. Nominating this bug nsbeta3+ at ekrocks request. If my av tells me the right thing (i.e., that the fix is the easy thing I think it is) then I'll fix it right away; otherwise, we'll find a new owner with the appropriate plugin knowledge. Ekrock: satisfied?
Marking Status with [nsbeta3+] as I think that was scc's intent. Setting priority to P2 as this is high profile partner and high profile backward compatibility--we'd really like to have RealPlayer supported on the Mac. ;-> Many thanks for jumping on this Scott! I don't understand the whole file type thing but yes, legacy Nav4 Mac plug-in binaries are supposed to work as-is within Moz/N6 and should be recognized and loaded just like newly-written plug-ins that support the Mozilla Plug-in API. I'll defer to Andrei on reviewing your proposed approach.
Priority: P3 → P2
Whiteboard: [nsbeta3+]
No, legacy plugins don't work, at least not if they have a JavaScript interface via the now obsoleted LiveConnect. I'm not sure what will happen if you try to run them but crashing seems likely.
In response to Nicholas Hart's comment, above: if your description is accurate, it should be working right now. See <http://lxr.mozilla.org/seamonkey/source/modules/plugin/nglsrc/ nsPluginsDirMac.cpp#86> Any file of type 'NSPL' is considered a plugin, reguardless of its creator. Technically, _this_ bug appears to be fixed ... however, there remains the problem of the RealPlayer plugin not being recognized. Nick, are you saying that if you change the plugin's creator type to 'MOZZ', then it works? If this is the case, then this bug is still valid and I need to figure out why the file type isn't being recognized in spite of the code that looks like it should do the right thing. If, on the other hand, just changing the creator to 'MOZZ' does not allow it to load, then there is some deeper plugin problem that deserves its own bug and a plugin savvy owner.
Well, ekrock, there you go then. Sounds like (according to Tim Maroney) there are fundamental infrastructure issues that prevent RealPlayer from running. Not this simple file type/creator bug. How do you want to proceed?
We do want moz to be able to load a binary that can also be loaded by n4 (single binary to maintain/distribute that implements an xpcom plugin with n4 plugin api entry points). The fact that scriptable 4x plugins won't work as 'expected' in moz/n6 isn't an issue for the bug at hand.
I was responding to Eric's statement that "legacy Nav4 Mac plug-in binaries are supposed to work as-is within Moz/N6." That's only true of plugins that don't use LiveConnect. It's relevant to this bug because there may be problems trying to run legacy plugins.
Moz already does load n4 plugins (note quicktime and flash bugs). This bug is specifically about loading dual xpcom/4x plugins from the bin/components directory/folder. The code referenced by Scott is probably not used in this case, since the plugin is not coming from the plugins dir.
Sean's last comment is true. This code is not used when loading an xpcom plugin. But I looked through xpcom loading and cannot immediately see the problem.
Just a quick note: The problem we have at RealNetworks is that we would like to ship one plugin binary. It needs to be MOSS/NSPL so that Communicator 4.x can load it. However, it will also support the XPCOM plugin API and will be installed in the mozilla/components folder. Currently NS6 PR2 does *not* recognize it as an XPCOM plugin. It doesn't appear to get registered and it doesn't show up in the navigator.plugins array. So, it would be very nice if the code that loads & registers XPCOM components would *also* look for MOSS/NSPL files in the mozilla/components folder. Thanks!
This might be the place to look: http://lxr.mozilla.org/seamonkey/source/xpcom/components/nsNativeComponentLoader .cpp#750 MOZZ/MOSS is not the issue, just the type. It looks like moz wants to see 'shlb' in the type. The '|| nspl' should probably go there.
Tim and I are now on the same page. In my earlier comment, I didn't have time to rehash the whole Mozilla Plug-in API doc: http://www.mozilla.org/docs/plugin.html ... so what I meant by "work as-is" in that context was of course that existing plug-in binaries should load as-is and support their non-LiveConnect functionality only. Sorry for any confusion caused by my brevity. (If we're going to be pedantic, I can fully expand this thought and add "... should support their non-LiveConnect functionality as-is on Win32 and Mac only, not Linux--except for the Flash binary, which supports its non-LiveConnect functionality on Linux!" ;-> ) Bottom line, yes it's critical that we fix this bug so that RealNetworks can release a single binary on the Mac that works in both Nav4 and Mozilla. Increasing priority to P1--high profile partner.
Priority: P2 → P1
Sean: do you build? Have you patched this and had success? If not, I'll patch according to your suggestion. Can you post or email me a link to the appropriate plugin with which to test this fix?
Sorry Scott, I'm building on windows and have not tested my theory that the problem lies in nsNativeComponentLoader. How about you Nick? Can you apply a patch and test it?
Unfortunately I don't have the mozilla build system set up on my Mac, and the last time I tried to set it up I couldn't get it working. So, I can't really try this proposed patch out very easily. Sorry.
PDT would like more info on why this is P1. Is the worst case that developers have to build multiple binaries? Or is there something more critical? And is anyone actively working on the architectural issues? Should we be at this late stage?
Whiteboard: [nsbeta3+] → [nsbeta3+][need info]
Hey Nick, What about changing the file type of your xpcom plugin from 'nspl' to 'shlb' to test the theory about what is preventing it from being loaded?
Adding acrobat, shockwave, flash, and beatnik keywords because on further reflection, I believe that this bug if not fixed will impact every single one of our plug-in partners who offers a Mac plug-in, including all of these high profile partners. cc:ing contacts at each partner for input; Liz, Miriam, Troy, Sean--please confirm that I'm right about this as I make the case for fixing this bug to PDT. If I understand this bug correctly, then if not fixed, it will force every vendor who offers a Mac plug-in to distribute two separate binaries (one for Nav4, one for Moz/N6) solely because Nav4 and Moz/N6 each recognize only a single (and different) file type right now. We need to assess the following issues: 0) If we don't fix this bug, then: a) We will massively increase the distribution costs for every single Mac plug-in partner by forcing them to maintain two distinct plug-in binaries, sniff which browser the user has, direct the user to the correct binary, and deal with the inevitable confusion and support costs. b) We will force plug-in vendors to modify and recompile their Mac plug-ins and/or the installer--*even if* the existing plug-in/installer would otherwise be backwardly compatible after all the work we've put in to achieving backward compatibility. 1) RealNetworks considers this a blocking issue for supporting Netscape 6. Want RealPlayer support for N6 Mac? 2) Adobe plans to support Acrobat for Netscape 6 via backward compatibility with the existing binary, so we need to make sure that Acrobat 4 for the Mac works as-is. Want Acrobat support for N6 Mac? 3) Want Flash support on N6 Mac? 4) Want Shockwave support on N6 Mac? Bottom line, a clear P1--multiple high profile partners. Plus, this should be an easy fix--we just need to have Moz/N6 recognize either file type. Clearing [need info].
Keywords: acrobat, flash, shockwave
Additional clarification from sean@beatnik: ----- Agree with everything that Eric wrote, except that this won't affect Adobe if they aren't going to distribute an xpcom plugin. Moz currently loads 4x plugins that are installed in the plugins directory without any problems. Single binary 4x/xpcom plugins are not installed to the plugins dir but to the components dir. Because Moz doesn't load files of type 'nspl' from the components dir, it is not possible to create a single binary 4x/xpcom plugin. ----- So: 1) 4x Mac plugins in the plugins directory load without trouble. 2) The problem is when you want to create a single binary 4x/xpcom plug-in. e.g for a plug-in which (like RealPlayer, Flash, or Shockwave, but unlike Acrobat) has a JavaScript LiveConnect API and needs to be upgraded. You need to install it to the components directory. But files of type nspl can't (because of this bug) be loaded from the components directory, so it's not possible to create a single binary 4x/xpcom plug-in. It is all the developers who wish to create single binary 4x/xpcom plug-ins on the Mac who are blocked by this bug. Enabling the creation of single binary 4x/xpcom plug-ins is one of the most central goals of the Mozilla Plug-in API. This bug won't affect Acrobat after all, but it still definitely blocks RealPlayer and will block Flash and Shockwave as well because they will likely wish to create single binary 4x/xpcom plug-ins as well. Removing acrobat keyword, but leaving flash, realplayer, shockwave. Still P1.
Keywords: acrobat
added beatnik to the list
Keywords: beatnik
With regard to the question posed by Sean, if I change the file type to shlb it *does* get loaded, but then promptly crashes the browser for some reason I have yet to determine. It seems to register ok, but if I try to use the about:plugins html page I threw together or actually embed it on a page it crashes. However, when the file type is "nspl" nothing happens.
PDT: Definitely NEED INFO on liklihood of a fix in the next few days and an assessment of the risk to fix. PR3 is almost out the door, if this will take very long or be risky, then it should get pushed out to RTM.
Attached patch possible fix — — Splinter Review
Attached a possible fix for this. UNTESTED/UNCOMPILED. Risk is limited to developers, unless a user copies a 4x plugin into the components directory. Even then, there will not be any xpcom entry points in the file, so risk is limited to how mCompMgr->RegistryLocationForSpec deals with files that don't have xpcom entry points.
"untested and uncompiled" sounds risky enough to me ;-) Marking nsbeta3- and nominating for rtm. Clearing need info given sean's patch.
Keywords: rtm
Whiteboard: [nsbeta3+][need info] → [nsbeta3-]
Escalating Severity to blocker as RealPlayer reports that this bug is blocking them from moving forward on a single binary plug-in for Nav4/N6. Scott--this is RTM must-fix. Please let us know ASAP if you can do this. If not, we need to find another resource. Thanks!
Severity: normal → blocker
It is certainly unclear to me that this can be made to work ... particularly based on the earlier comments of people significantly more familiar with this code than I am. If this bug absolutely has to be fixed, you'd better re-assign it to somebody who has the big picture for plugins, e.g., av@netscape.com. I'll provide all the Mac assistance he needs, but as far as I can see, it's going to take a plugins expert to even know that this can work, right? ekrock, I'll re-assign this bug to you (and cc myself) so you can get it to the right person.
Assignee: scc → ekrock
Status: ASSIGNED → NEW
Re: accepting Sean's patch ... this patch is totally un-tested (as he himself points out). It's not even known if it _should_ work, right? No info was even provided in the bug on how someone with a Mac and the ability to build _could_ test it. Nicholas Hart's comment of 9-22 makes me wonder if the underlying support is available to make this work. No information was supplied in response to my question of 9-20 to test this myself and no one else has stepped up to the plate.
A possible testcase for this might be the MRJ plugin http://lxr.mozilla.org/seamonkey/source/plugin/oji/MRJ/plugin/. Maybe Patrick Beard might have something to add to this bug... I don't know much about MRJ except that it's an XPCOM mac plugin. One could build MRJ, change the type to 'nspl' and see how mozilla handles it (does it get loaded and function with and without a potential fix?).
Reassigning to bnesse who's been helping Andrei with Mac plug-in issues. Brian, this is an RTM stop-ship bug RealPlayer blocker on the Mac. Can you do this for RTM? If not, please call me at my extension so we can track down someone else who can help. cc:ing sdagley who's been a lifesaver for plug-ins on the Mac in the past as well IIRC.
Assignee: ekrock → bnesse
Whiteboard: [nsbeta3-] → [nsbeta3-][rtm need info]
I believe that the solution has been touched upon a couple of times in this thread, but I think there is some misunderstanding going on as well. The plug-in code looks through the "Plugins" (and now also the "Plug-ins") directory searching for files of type NSPL. Any files that it finds are added to the list of available plug-ins. I'm pretty certain that the root of the problem here is that the plugin code ALSO needs to search the components directory (which it does not currently appear to be doing.) I don't know if this will require an additional plug-ins list or if the current code will deal with plug-ins which are located in multiple directories. This is well outside of my area of knowledge regarding plug-ins so hopefully someone (av?) will have some thoughts about the difficulties involved in making this work.
XPCOM plugins (located in the components directory) should be discovered correctly as is if the plugin is of type shlb. XPCOM plugins populate a special registry key that the plugin manager/host uses to populate the plugins list. see bug 37504 The problem is that mozilla won't load components of type 'nspl' from the components directory.
Ok, this is where my ignorance comes through. I have no idea whether an XPCOM plug-in is considered to be a component and therefore managed by the component manager or a plugin and therefore managed by the plugin manager. If it's a component, then Sean is correct and the component manager needs to deal with files of type NSPL. If it's a plugin, then the plugin code needs to scan the component directory.
I ref'd bug 37504 for background on this bug - should've been bug 45698 (37504 spawned 45698, this one and a couple others)
To my understanding xpcom plugins register themselves as plugins and the plugin detection code browses through the registry in search for them. Then it goes to Plugins folder to search for the legacy plugins and combine both types into the single list. Brian, are you saying that we need to scan commponents dir for legacy plugins?
Unfortunately just making the component loader load NSPL files, the easy/obvious fix, doesn't seem to be a 'real' fix (see comments from Nicholas Hart on 2000-09- 22 and pardon the pun :-)
Nick: Does your single binary 4x/xpcom plugin load and work correctly (less scripting) when installed to the mozilla/plugins directory on Mac?
You have to remember that we have no "registry" concept on the Mac. The only way we can find plug-ins is to scan for them. Right now we only scan the "Plug-ins" directory, thus we only know about plug-ins which have been placed in that directory. If we want to load plug-ins from elsewhere, we need to scan elsewhere.
(apologies for a possible duplicate post - bugzilla was acting up) Time for a summary: All references in this bug to 'registry' are to the moz xpcom registry - see bug 45698 for how xpcom plugins register themselves. Mozilla only does brute force directory scanning of legacy plugins. Legacy plugins are not xpcom plugins. xpcom plugins can implement legacy api entry points such that they can also run in n4. On macs, legacy plugins must have file type nspl. xpcom plugins are not installed in the 'plugins' directory. They are a special subset of xpcom components and are installed in the components directory. Moz won't load components of type nspl (they must be type shlb).
So IIUC the problem is that: a) a single-binary plug-in that supports both Nav4 and Moz/N6 must be written as an xpcom component (with legacy entry points) b) xpcom components must be placed in the components directory when installed in Moz/N6 and be of type shlb to be findable and loadable by Moz/N6 on Mac c) ... but when placed in the Nav4 plug-ins directory, a plug-in binary must be of type nspl to be recognizable and loadable by Nav4 on Mac ... so with the current setup, a single-binary Nav4/Moz plug-in on the Mac must have one file type to be loadable by Nav4 and another file type to be loadable by Moz, making it currently impossible to produce a working single-binary plug-in on the Mac--an obvious blocker for RealPlayer and any other plug-in vendor who wants to create a single-binary plug-in. OK, so that's the problem. Many thanks to all for the analysis! Now, how do we fix it? Do we modify the Moz xpcom component search/load code so that it also loads files of type nspl? (Obviously, retroactively changing Nav4 for Mac to recognize files of type shlb is not possible.) Adding waterson and warren for input on XPCOM issues.
From what I've been able to determine we need to load 'NSPL" files from the components directory. When the plug-in code starts up, it then needs to scan the "Plug-ins" folder for legacy plug-ins, and then interface with the component registry to "learn about" xpcom plugins (or do this part first possibly.) My build currently looks for 'NSPL' files but, using the MRJ plug-in as a test case, doesn't appear to actually load the plugin. There could be any number of reasons for this, including the possibility that the MRJ plug-in simply isn't up to date with the latest plug-in detection code.
The MRJ plugin does not appear to have been updated to reflect the new plug-in registration process. This is probably because beard hasn't been cc'd on any of this process and isn't aware of the changes (adding beard to cc list.) The plugin sample (Simple) does not exist on the Macintosh. There isn't even a project to build it. Sean doesn't have a Mac plug-in and Nicholas is out of the office until the 18th. Essentially I have no test case. I have hacked together a "Simple" project for the Mac which builds a 4.x/Mozilla combination plugin. The legacy portion works correctly when installed in the plug-ins folder. If I put it in the components folder, however, it crashes Mozilla on launch (not when trying to use it as per Nicholas' comment on 2000-09- 22.) Most likely I screwed something up trying to integrate watersons' changes into the Mac specific code, but I haven't had a chance to debug.
I'm don't think we can test that the fix for 45697 is working using the Nav4.x Mac RealPlayer for the following reason: 1) Yes, the legacy Nav4.x Mac RealPlayer has type nspl. 2) Yes, we can therefore use it to confirm that plug-in binaries of type nspl are loaded from the "plug-ins" directory. 3) However, the Nav4.x Mac RealPlayer binary is *not* an xpcom component. Plug-ins will only be loaded correctly from the "components" directory if they are XPCOM component binaries that implement the plug-in API. A legacy Nav4.x plug-in binary dropped into the "components" directory won't work. So I don't think we can test that the fix for 45697 is working using the Nav4.x Mac RealPlayer plug-in binary. Unfortunately, we really need a true single-binary Nav4/Moz XPCOM plug-in binary. Brian's tried valiantly to hack together something to test it fully but without complete success so far. I hate to see him wasting more cycles at this point in the development cycle trying to hack together a one-off solution just because Nick is on vacation at your end. Is there *any* way you can get us a build of your updated binary? Surely, someone else than Nick on your side can turn on his machine, build it, and email it to us, yes? Could you please explore whether there is *any* way to make this happen? Sean, could you provide us with a single-binary Beatnik Mac plug-in binary to test with?
The crash I was seeing, it turns out, was actually the second half of the bug. There are two pieces to this bug. The first sean has already identified [attachment (id=15364)]. The second half is a fix in the plugin host implementation so it returns a valid path when asked for one.
The change is good and looks perfectly safe. r=av Eric, would you please lobby plusplussing?
av, bnesse: Please get it reviewed and super-reviewed and mark it rtm+ when that's done. Please do ASAP as PDT's getting harsher every day. PDT: 1) bnesse has since found a way to test and verify this using his own plug-in, so we now have verified that this works without needing access to Real's updated binary. 2) Please read my earlier comments in this Description from 2000-10-10 to understand what this fixes, why, and how, and my comments from 2000-07-18, 2000-09-21, and 2000-10-05, for info about why this is must-fix for RTM. Fix is low risk; we simply recognize xpcom component (native Mozilla plug-ins) of type nspl in the "components" directory instead of ignoring them. This must be fixed to make possible the distribution of single-binary plug-ins that support both N6/Moz and N4. Blocker for RealPlayer for Mac for Moz/N6 and other upgraded Mac plug-ins that fully support LiveConnect content. If you're even thinking of minusing this, please call me and I'll rope in engineering to assess risk and explain necessity. Thanks!
sr=scc.
Reviewed and super reviewed. Marking rtm+ as per eric's request.
Whiteboard: [nsbeta3-][rtm need info] → [nsbeta3-][rtm+]
sr=scc.
Cleared nsbeta3- for good measure :)
Whiteboard: [nsbeta3-][rtm+] → [rtm+]
rtm++
Whiteboard: [rtm+] → [rtm++]
Since you pulled the beta3-minus, I'll pull the beta3 keyword, so that this bug won't get additional re-triage
Keywords: nsbeta3
Changes checked in on the trunk. Still building on the branch.
Changes committed to branch.
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Nick's comments fro memail : > Yep-- it's fixed. Or at least... it seems to be fixed. The plugin definitely > gets registered and Mozilla "wants" to load it, but then crashes as per bug > 57885. marking this VERIFIED to get off the rtm++ radar.
Status: RESOLVED → VERIFIED
Keywords: beatnik, rtm → nsrtm
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: