Closed Bug 608595 Opened 10 years ago Closed 10 years ago
Binary components of add-ons aren't loaded anymore since data-driven-compreg has been landed
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b8pre) Gecko/20101027 Firefox/4.0b8pre Since the data-driven-compreg patches on bug 568691 have been landed, binary components shipped with add-ons aren't getting loaded anymore. Looks like that we don't register those components after the add-ons manager has registered the add-on itself. I have seen that behavior while working on our MozMill crowd extension which is using the IPC-PIPE component from bug 68702. After building the binaries for 32bit and 64bit and putting those in the appropriate folders below the platform folder, they don't get registered during start-up. I will attach a copy of the extension which should be extracted into the extensions folder of a profile. I request blocking Beta 7 because it's really important for add-on authors to be able to use their binary components.
(In reply to comment #1) > Created attachment 487232 [details] > example extension I forgot to mention that this extension only supports OS X, but both 32-bit and 64-bit platforms.
The attached extension isn't correctly registering its binary component https://developer.mozilla.org/en/XPCOM/XPCOM_changes_in_Gecko_1.9.3#Binary_components
Status: NEW → RESOLVED
blocking2.0: ? → ---
Closed: 10 years ago
Resolution: --- → INVALID
Thanks Dave. I made those changes and it still hasn't worked. Finally I found the problem in the MDC documentation and updated it, so we are using Darwin_x86_64-gcc3 now. It works fine now, but sadly the loaded components aren't dumped to the console when logging is enabled. Only the application wide modules get dumped. Is there already a bug for that on file?
Status: RESOLVED → VERIFIED
Component: XPCOM → Extension Compatibility
Product: Core → Firefox
QA Contact: xpcom → extension.compatibility
You need to log in before you can comment on or make changes to this bug.