574334 - Binary XPCOM components registration or handling procedure bug crashes Firefox 3.6.4 (no problem with 3.6.3 and earlier)

Status: RESOLVED INCOMPLETE

(Firefox :: Extension Compatibility, defect)

Description

[Mathias]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.4) Gecko/20100611 Firefox/3.6.4
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.4) Gecko/20100611 Firefox/3.6.4

We found an issue in 3.6.4 that is related to the to the binary XPCOM components registration or handling procedure. Our iMacros extension from contains a file called XpcomOpusConnector.dll - normally the file just sits in this directory and does nothing (unless iMacros for Firefox is started/used with our so called Scripting Interface).

But since 3.6.4 the pure presence of this file stops Firefox from loading! Even on Linux, although XpcomOpusConnector.dll is a Windows binary.

I will now upload a new version of iMacros to AMO without that file, but please investigate and fix this issue soon. It breaks a core function of our extension. If there is anything that we can do from our site, please let me know.

Reproducible: Always

Steps to Reproduce:
Install iMacros for Firefox V6.6.5, https://addons.mozilla.org/en-US/firefox/addon/3863/versions/?page=1#version-6.6.5.0


Actual Results:  
Firefox will no longer start after reboot, see also the user reports at http://forum.iopus.com/viewtopic.php?f=11&t=10454

Expected Results:  
Firefox starts!

Comment 1

[Kevin Brosnan]

Just having the Firefox extension is not enough to cause the issue. I had to install the free trial of iMacros http://iopus.com/download/

Comment 2

[Kevin Brosnan]

The windows crash handler produced the following set of files. http://dl.dropbox.com/u/686313/Windows%20Firefox%20dump.zip

Comment 3

[Kevin Brosnan]

Attachment: Stacktrace from the mini dump

Comment 4

[Mathias]

>I had to install the free trial of iMacros http://iopus.com/download/

Strange. We also saw the issue on Linux, and for Linux only the iMacros Firefox addon is available.

Comment 5

[Jon Peatfield]

I think we may be seeing a similar behaviour with the "MR Tech toolkit" extension https://addons.mozilla.org/en-US/firefox/addon/421/ (currently release 6.0.4).

One of our users reported problems after we updated to Firefox 3.6.4 (BTW this is the SL5/RHEL5 Linux package), testing it myself I find that after adding the extension it restarts firefox and seems ok, but after quitting any later attempt to start it results in a segv.

Going into the extensions/{9669CC8F-B388-42FE-86F4-CB5E7F5A8BDC}/ and taking a look about I find that if I manually rename components/nightly.xpt to (say) components/nightly.xpt.OFF then firefox no longer crashes and the extension appears to work ok.

Another hack is to remove the extensions.ini which lets firefox work *just* for the next time it is started (and then it gets recreated with the same contents) so it seems to be related to whatever processing is done there.

I'm tempted to tweak our firefox wrapper we have to always delete all the extensions.ini files but that does seem rather evil...

 -- Jon

Comment 6

[timeless]

you register two category entries:
       content-policy,@iopus.com/requestwatcher;1,@iopus.com/requestwatcher;1
       net-channel-event-sinks,@iopus.com/requestwatcher;1,@iopus.com/requestwatcher;1

the latter is triggered by nsIOService::OnChannelRedirect,
and the former is triggered by content policies, the also will definitely trigger.

If you don't want it to do anything, you need to dynamically register them (for the process) based on some condition

As for why it's getting stuck, that's because of how you're using COM

it isn't our problem :/

Comment 7

[Kevin Brosnan]

(In reply to comment #5)
You should file a separate bug.

Comment 8

[Jon Peatfield]

(In reply to comment #7)
> (In reply to comment #5)
> You should file a separate bug.

Sorry I thought it might be the same issue.  New bug filed (https://bugzilla.mozilla.org/show_bug.cgi?id=574458)

Comment 9

[Mathias]

Hi timeless (In reply to comment #6)

I am not sure what you mean with your comments.

The DLL has been there and unchanged for years. What change in 3.6.4 would trigger this crash? And on Linux, this DLL has no function whatsoever and Firefox still crashes (= does not start). Is there anything we should do in  another way now??

"As for why it's getting stuck, that's because of how you're using COM "
It is not clear to us what you mean. Is it related to dll XPCOM or Javascript XPCOM?

Comment 10

[timeless]

the dll calls MSCOM...

as for the linux side, someone would have to trace it to something happening, kbrosnan provided a stack trace for the windows side, but i don't have one to look at for the linux side.

Comment 11

[Daniel Veditz [:dveditz]]

(In reply to comment #9)
> The DLL has been there and unchanged for years. What change in 3.6.4 would
> trigger this crash? And on Linux, this DLL has no function whatsoever and
> Firefox still crashes (= does not start). Is there anything we should do in 
> another way now??

Without knowing what your DLL does there's no way for us to know. We changed a lot (234 bugs) and only you know what interfaces/services you were using.

https://bugzilla.mozilla.org/buglist.cgi?quicksearch=ALL%20status1.9.2%3A.4-fixed

Anything in there look relevant to what you're doing? Maybe an hg diff of 3.6.3 vs 3.6.4 and focus on changes in .idl files?

Comment 12

[Mathias]

Would the xpt DLL source code help you? It is actually a pretty small project and I can provide it.

But since the issue also happens on Linux (where the dll does not work), I assume it is not related to a function of the DLL anyway. Does Firefox parse xpt files at startup?

We found that renaming IOpusConnector.xpt to IOpusConnectorYYYY.xpt avoid the startup crash (of course, then the extension features that require the xpt no longer work, too)

Comment 13

[timeless]

as long as the license isn't poisonous, it couldn't hurt. i can't make any guarantees.

Comment 14

[Mathias]

I am not sure what you mean with "poisonous" in this context. iMacros for Firefox is under a proprietary license but open source. So this does not prevent you (or anybody else interested in it) to have a look at the source code.

But on the other hand, we are pretty sure that "our" bug is the same as

https://bugzilla.mozilla.org/show_bug.cgi?id=574458

So probably it makes sense to wait until 574458 is fixed before continue to work on this one.

Comment 16

[Michelle Funches - QA]

Need to determine if this bug can be closed. Related items have been fixed. iMacros for Firefox 8.9.6 WFM
Version 6.5.0.0 cannot be installed on 
Version 	45.0
Build ID 	20160303134406

Comment 17

[Michelle Funches - QA]

Closing this as incomplete due to inactivity and lack of response. 
Feel free to reopen the bug and provide a test case with updated info, if the issue still reproduces on a current build.