I get these console messages on clicking the Install button on the dialog: Error: installLocation has no properties Source File: file:///home/nrthomas/firefox-1.8branch/components/nsExtensionManager.js Line: 7729 Error: installLocation has no properties Source File: file:///home/nrthomas/firefox-1.8branch/components/nsExtensionManager.js Line: 7741 Those are Linux line numbers, the Windows ones are 7789 and 7901; use 7788 and 7900 when looking at nsExtensionManager.js.in. Steps to reproduce: 1, Start 20060913 or later nightly build from 1.8 branch and make new profile 2, install an extension (doesn't seem to matter from where, I tested with a local file) 3, Observe error console It doesn't seem to be terminal for the extension install, they work after restart. This started with the 20060913 branch nightly (0910, 0912 tested ok). Lots of checkins in that window: http://tinderbox.mozilla.org/bonsai/cvsquery.cgi?treeid=default&module=all&branch=MOZILLA_1_8_BRANCH&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2006-09-12+03%3A00&maxdate=2006-09-13+05%3A00&cvsroot=%2Fcvsroot including bug 346498. There were also several JS engine changes that occurred between the 12th and 13th nightlies. When we were trying to investigate this on IRC there was the suggestion that other parts of Firefox was giving "no properties" errors. Someone (with a "clean install and new profile") had: Error: dialog has no properties Source file: chrome://mozapps/content/downloads/unknownContentType.xul Line: 1 Error: aElt has no properties Source file: chrome://global/content/customizeToolbar.js Line: 667

From the looks of the addons UI, it's installs view appears to try to retrieve the hidden property from installs it's displaying. I don't believe that at this point the installLocation has been set for the install, and the code from bug 346498 fails when there is no installLocation. I'm not sure why the same error is coming from the installDate property, in fact I cant even see where this is ever referenced. I guess a quick (and probably reasonably safe fix) would be to just check there is a valid installLocation and if not return sensible values. I'm requesting blocking here because there could be potentially something more nasty going on and this needs to be evaluated before Firefox 2.

Mike, this is a no brainer fix I wish I had caught sooner

Note that one of the errors is inside the installDate property, which that patch doesn't touch.

Interesting... I haven't seen that error previously and the patch in bug 346498 didn't touch that. I thought there was actually a visible problem besides the error in the console. If that is the case then this shouldn't block. btw: did you also file bugs for customizeToolbar.js and unknownContentType.xul... they have nothing to do with this bug.

Prevents an error in the error console.

*** Bug 352883 has been marked as a duplicate of this bug. ***

*** Bug 352883 has been marked as a duplicate of this bug. ***

Nick, did you also file bugs for customizeToolbar.js and unknownContentType.xul since they have nothing to do with this bug?

I can't reproduce the customizeToolbar.js with random addition/removal of items to the toolbars (IRC reporter didn't give step to repro). Looks like the unknownContentType.xul error is bug 313828. Sorry for the confusion.

Comment on attachment 238656 [details] [diff] [review] simple fix 2 - If it doesn't have an installLocation then it isn't in a restricted location r+a=me, please get this in by 6 PM PDT Sunday evening (if you're not around, I can land it)

Checked in to MOZILLA_1_8_BRANCH and trunk