Closed Bug 45697 Opened 24 years ago Closed 24 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: 24 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: