Classes with the same name, but in different plugins collide




9 years ago
9 years ago


(Reporter: brian.postow, Unassigned)


Firefox Tracking Flags

(Not tracked)


User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv: Gecko/20100401 Firefox/3.6.3
Build Identifier: 3.6.3

I have a plugin (Mac, in Objective-C) with a ProgressController Class. I have a user who is getting the following error:

objc[19559]: Class ProgressController is implemented in both /Users/Steve/Library/Application Support/1Password/Extensions/30621/ and /Library/Internet Plug-ins/Accel ViewTIFF.bundle/Contents/MacOS/Accel ViewTIFF. One of the two will be used. Which one is undefined.

Now since this error was arrived at while USING Accel VIewTIFF, it sort of makes sense that the one in that bundle would be used... 

Reproducible: Always

Steps to Reproduce:
Since it's my user who's having the problem, and I'm not exactly sure what 1password is I haven't reproduced it, but it happens every single time for him... I *THINK* it should come up whenever you have two plugins (or a plugin and an extension) that have a classes with the same name.
Actual Results:  
The wrong class is used, at least SOME of the time

Expected Results:  
The class in the bundle that is being run should be used.
You should be able to compile your dylib/bundle with hidden-visibility symbols, and/or use two-level namespace lookups to make sure that symbols don't collide. In any case, it's really up to you and the other vendor, there's not anything Firefox can do about it. You can also put all your stuff in a c++ namespace, which is usually not that hard.
Closed: 9 years ago
Resolution: --- → INVALID
But doesn't my plugin have its own namespace to begin with? 

I'm not sure what hidden-visibility will solve. I need the OTHER products symbols to be hidden... And I'm not sure how to set up a two-level namespace. Can you point me at a useful doc? 

Since I'm writing everything in Objective C, which doesn't have namespaces, that's not really going to help either.

I *CAN* prefix all of my classes and globals with ACDX or something equivalently unlikely to conflict with anyone but I didn't think that that was necessary. Also, it's not documented anywhere.

Actually, if my classes can have name conflicts with other people's classes, why can't my functions (like NPP_HandleEvent for example) conflict? It's all in the same namespace isn't it? Do I have to rename every (non-member) function as well, in case someone else based their plugin off of the BasicPlugin example?

> But doesn't my plugin have its own namespace to begin with? 

No.  Plug-ins are just dynamic-link objects that are linked into the application binary at runtime.  The namespace is determined at _compile_ time and affects symbol mangling which produces the runtime symbol names.
You need to log in before you can comment on or make changes to this bug.