User Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0a1) Gecko/20110809 Firefox/8.0a1 Build ID: 20110809030751 Steps to reproduce: Removed my Lightning comm-central add-on, attempted to install it from a fresh file. Actual results: After choosing the fresh file with the add-on manager file picker, the add-on screen did not update. I observed an error in Error Console, Error: win is null Source File: chrome://messenger/content/specialTabs.js Line: 1065 This pointed to the last line in the following code from omni.jar!/chrome/messenger/content/messenger/specialTabs.js, xpInstallObserver: { observe: function (aSubject, aTopic, aData) { const Ci = Components.interfaces; let brandBundle = document.getElementById("bundle_brand"); let messengerBundle = document.getElementById("bundle_messenger"); let installInfo = aSubject.QueryInterface(Ci.amIWebInstallInfo); let win = installInfo.originatingWindow; let notificationBox = getNotificationBox(win.top); I changed "win" with "window" and the Javascript error disappeared, but I still could not see any feedback from my attempt to install the add-on. Expected results: Either a pop-up window should provide reasons for not installing the add-on, or the add-on list should update and the new add-on should highlight.

(a) I figured that the bug occurs only when attempting to install an incompatible Lightning build from its top-level download directory, http://ftp.mozilla.org/pub/mozilla.org/calendar/lightning/nightly/win32-xpi/ as opposed to the proper build in the latest-comm-central sub-directory, http://ftp.mozilla.org/pub/mozilla.org/calendar/lightning/nightly/latest-comm-central/win32-xpi/ (b) The bug does NOT occur with an August 2 nightly build of Shredder, http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/2011-08-02-03-01-33-comm-central/ The bug occurs with all subsequent builds such as the one from the next night, http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/2011-08-03-03-01-08-comm-central/

Igor is Firefox nightly behaving the same way ?

I've just tested Firefox - installing an incompatible add-on from a file causes exactly the same failure. Given the regression range, my best bet is bug 670023 being the one that caused this. STR: 1) Find an add-on incompatible with current trunk and download it to disk 2) Go to Tools -> Add-on Manager and then select the menu with Install Add-on from File. 3) Nothing happens. See comment 0 for the errors on the error console (similar code for FF).

Blair can you either figure this out or backout the strict mode patch before the merge on Tuesday

Simple fix. Testing it, however, is another story. Would like to punt that to a litmus test. (Fwiw, it was only the browser notification that was broken - it still installed fine.)

Comment on attachment 553097 [details] [diff] [review] Patch v1 Could you test this by at least verifying that the observer notifications are getting sent?

Indirectly testing via observer notifications.

litmus test for 6.0 branch https://litmus.mozilla.org/show_test.cgi?id=25824 litmus test for aurora branch https://litmus.mozilla.org/show_test.cgi?id=25825

(In reply to Maniac Vlad Florin (:vladmaniac) from comment #10) > litmus test for 6.0 branch https://litmus.mozilla.org/show_test.cgi?id=25824 > litmus test for aurora branch > https://litmus.mozilla.org/show_test.cgi?id=25825 Those tests are duplicates of a test I have added a while back. Not sure why those have been added again. https://litmus.mozilla.org/show_test.cgi?id=15218 I have removed both new tests.

(In reply to Mark Banner (:standard8) from comment #3) > 1) Find an add-on incompatible with current trunk and download it to disk > 2) Go to Tools -> Add-on Manager and then select the menu with Install > Add-on from File. > 3) Nothing happens. Those steps work fine for me now with incompatible extensions and Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0a2) Gecko/20110824 Firefox/8.0a2

This seems to have made Aurora. Do we actually need to track this.

(In reply to Asa Dotzler [:asa] from comment #13) > This seems to have made Aurora. Do we actually need to track this. I don't think so - it mainly affected other XULRunner applications, where Install from File may be the main method of installing addons (which isn't the case for Firefox).

(In reply to Blair McBride (:Unfocused) from comment #14) > I don't think so - it mainly affected other XULRunner applications, where > Install from File may be the main method of installing addons (which isn't > the case for Firefox). Even under this principle we have to ensure it's working in Toolkit. But since this fix landed for Firefox 8 and the strict mode has been enabled starting with Firefox 8, we should indeed be ok here.

---------------------------------[ Triage Comment ]--------------------------------- This looks like it already landed for Firefox 8 when it was on mozilla-central so we don't need to track.