At APN, we compiled a binary component for FF4, using an old XULRunner SDK. Module::kVersion was 1, and with the FF5 Aurora code changing that to 2, we expected we needed to recompile for FF5. However, in smoke-testing, I discovered that XPCOM code is not checking the Module::kVersion field of the component it is registering. This means that a binary component compiled for one version of XPCOM (including an invalid version like 220) would be enabled across all versions of XPCOM from Gecko 2.0+. I recognize that Module::kVersion was changed for a reason, to force binary components to update. Allowing mismatched kVersion fields means an incompatible DLL could register - or worse, supersede a properly compiled DLL for that version of Firefox (see bug 616056 for details).
Created attachment 531663 [details] [diff] [review] Actually do the version compare, rev. 1
Assignee: nobody → benjamin
Status: NEW → ASSIGNED
Attachment #531663 - Flags: review?(bzbarsky)
Comment on attachment 531663 [details] [diff] [review] Actually do the version compare, rev. 1 r=me
Attachment #531663 - Flags: review?(bzbarsky) → review+
Status: ASSIGNED → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED
Attachment #531663 - Flags: approval-mozilla-aurora?
Discussed in triage today - we'd like to approve this, but given that we've missed it before, it needs a test.
Affects Fx4 but extremely unlikely we'll ship an extra release for this. Fx5 is coming soon.
blocking2.0: --- → -
status2.0: ? → wanted
If no one beats me to it, I can work on the testcase tonight, using Mozilla-only code.
Created attachment 531837 [details] [diff] [review] testcase as patch
Attachment #531837 - Flags: review?(benjamin)
Comment on attachment 531837 [details] [diff] [review] testcase as patch brilliantly simple
Attachment #531837 - Flags: review?(benjamin) → review+
Totally nitpicky, but our modern Makefile style is two-space indent after line continuations, like: EXTRA_DSO_LDOPTS = \ $(NSPR_LIBS) \ ... $(NULL)
Check-in needed for trunk. Per comment 4, this is a prerequisite for FF5 Aurora.
Flags: in-testsuite? → in-testsuite+
Comment on attachment 531663 [details] [diff] [review] Actually do the version compare, rev. 1 a=me on this patch and the accompanying test once it runs clean on central. Thanks for the quick turnaround!
Attachment #531663 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Please land for Aurora by Monday May 16 or the approval will potentially be lost. Please mark as status-firefox5 fixed when you do.
status-firefox5: --- → fixed
There is a bug in /xpcom/components/nsNativeComponentLoader.cpp! >> if (mozilla::Module::kVersion == data.module->mVersion && ... I think there should be "<=" instead of "==", cause: * in Firefox7a - kVersion=7 * in Firefox6a - kVersion=6 * in Firefox5b - kVersion=2 For example XPCOM component built with old SDK supports Firefox7a with kVersion=7. If this component will be running under Firefox5b with the fix I wrote above - all will be fine: mozilla::Module::kVersion = 2; data.module->mVersion = 7; 2 <= 7 == OK
No, this is intentionally ==. Binary components must be recompiled for each release per our new policy.
So you think that I should have for example 3 XPI files with different XPCOM files for 3 different versions of Firefox??? Or should I include 3 different XPCOM files (with similar source code, but different kVersion value in Module unit) in one XPI file? What's a reason for this? I think Firefox must have backwards compatibility with older versions.
I understand all that you wrote. But for example my XPCOM dll has only 1 class which doesn't use any other FF interfaces. It just allows to connect from JS-code (through the methods of my own interface/class) with my stanalone EXE application to obtain some info & vice versa - my EXE can connect to JS-code. P.S. If someone will delete any service from FF7 for example - I think you'll got the NULL as a result when you query that service. Am I right?
It sounds like you'd be better served using js-ctypes then, which will let you call your C++ code from JS without any XPCOM in between, and without a need to recompile for each Firefox release: https://developer.mozilla.org/en/js-ctypes/Using_js-ctypes
"js-ctypes" is not usable for me, cause 1st of all from my JS-code I need to know where the DLL is located. 2nd - it's too difficult to use js-ctypes functions, in XPCOM I have scriptable interface which allows to use "in" & "out" params in a simplest way.
These are both solvable problems, but this discussion should move to a newsgroup, not a bug: http://www.mozilla.org/about/forums/#dev-platform or http://www.mozilla.org/about/forums/#dev-extensions In any event, you are welcome to continue using binary XPCOM components, you will just have to recompile them for every version. That's the trade-off, sorry.
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0) Gecko/20100101 Firefox/6.0 I was trying to see if this is fixed for Fx6 since the flag "status-firefox6" is set on "fixed", but I couldn't. Is there a test case or any steps / guidelines for this bug that can be used to verify the fix? Thanks
Find a binary component compiled against an earlier version and try to register it in Firefox 6? I doubt this needs additional verification, though, since there has been plenty of discussion about it in the groups.
You need to log in before you can comment on or make changes to this bug.