User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.7.3) Gecko/20040913 Firefox/0.10.1 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.7.3) Gecko/20040913 Firefox/0.10.1 Clicking on an XPI to install an extension does not work properly when Firefox is launched with the disk cache disabled (Set to 0). Reproducible: Always Steps to Reproduce: 1. Select TOOLS - OPTIONS - PRIVACY - CACHE 2. Set Use Up To: to 0 bytes and click OK. 3. Try to install an extension from update.mozilla.org Actual Results: After clicking the Install button, an error occurs: Firefox could not download the file at http://ftp.mozilla.org/pub/... (etc) because: Download error Expected Results: Extension downloaded and installed. Workarounds: 1. Temporarily enable disk cache and disable after installing the extension 2. Download the XPI locally and do a FILE - OPEN on it. This was originally posted as Bug 254318 with a cause of using the -profile switch. As it turns out that this wasn't the cause at all and the description was wrong, I have opened this bug instead.
This bug is also relevant for the very cool "Portable Firefox" (browser on a USB stick), because the installation disables the cache (to reduce wear-and-tear on the USB stick. http://johnhaller.com/jh/mozilla/portable_firefox/ And just for fun: http://johnhaller.com/jh/mozilla/portable_thunderbird/
Confirming that this is a cross-platform bug. I just tested Firefox 0.10.1 on Mac OSX and experienced the same behavior. Same error message as well. Re-enabling the cache allows the extensions to install. User Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-0; rv:1.7.3) Gecko/20041001 Firefox/0.10.1 Setting Platform and OS to all. Can someone on Linux please confirm? I only have Knoppix handy at present. Sidenote: Yes, this is important to Portable Firefox as well. That's originally how I found this bug (and why I thought it was related to -profile at first).
Setting blocking-aviary1.0 to ? to get a decision on whether this should block.
Darin, do you think this is a network issue?
This bug has already been reported as bug 259428.
*** Bug 259428 has been marked as a duplicate of this bug. ***
*** Bug 267636 has been marked as a duplicate of this bug. ***
As a temporary fix we should add a string to the box w/ the download error saying. "Possible causes could be your cache is not large enough or turned off."
Created attachment 164702 [details] http log This bug is reproducible with Fx0.9 on winXP as well (no error dialog though). > 0[3a4fd0]: nsHttpChannel::ReadFromCache [this=28534a8] Using cached copy of: http://cgi29.plala.or.jp/~mozzarel/addon/firefox1_0/bookmarksftp/bookmarksftp0_10_4.xpi > 0[3a4fd0]: nsHttpChannel::ProcessResponse - case 206: [this=28534a8 ,rv=0 ,mStatus=0 ] > 0[3a4fd0]: nsHttpChannel::OnStartRequest [this=28534a8 request=2767eb0 status=80070057] When nsHttpChannel::on*Start*Request is called, nsHttpChannel::mStatus is already NS_ERROR_ILLEGAL_VALUE (0x80070057). * If cache size is 500K, mStatus is 0 and everything works fine. * Even if cache size is 0, loading normal html files doesn't return NS_ERROR_ILLEGAL_VALUE.
Created attachment 164704 [details] [diff] [review] patch v1.0 (workaround) On the other hand, I don't think cached XPI files are useful for anybody, so there's no problem with ignoring cache (like ctrl + F5) at all. If XPInstaller always fetches the latest package, this bug would be invisible.
*** Bug 271119 has been marked as a duplicate of this bug. ***
12 years ago
(In reply to comment #12) > maybe caused by bug 126344 No, I doubt it. nsDownloader does handle errors returned from SetCacheAsFile (see bug 209560). Anyways, the workaround suggests that inhibiting caching altogether helps somehow. Do we know for sure that nsDownloader is even being used here?
ah, hm... it seems that xpinstall implements the nsDownloader functionality manually. http://lxr.mozilla.org/seamonkey/source/xpinstall/src/nsXPInstallManager.cpp#895
*** Bug 260978 has been marked as a duplicate of this bug. ***
Dan, I don't see this as a blocking problem, but I also don't see problems with the patch you attached.
Hmm.. I'd recommend against the current patch unless we run out of time to fix the real problem.
*** Bug 300617 has been marked as a duplicate of this bug. ***
Is this bug still valid after all the extensions manager work lately?
(In reply to comment #19) > Is this bug still valid after all the extensions manager work lately? I was able to get extensions to install with the cache disabled within FF 1.0.7 and 1.5b2. But at least once, I did run across this same message in 1.5b2 when trying to install Sage from addons.mozilla.org. I clicked Install Now again and it worked fine. I could not determine the reason.
The bug appears to still be present in Firefox 1.5 RC1. While I can install multiple extensions from addons.mozilla.org, others have failed. One example is Bookmark Backup 0.4 which fails from this website: http://www.pikey.me.uk/mozilla/?addon=bb You have to whitelist it first, but then clicking the XPI should install. Instead, you are presented with the same download issue as originally reported. The workaround of locally downloading the XPI remains.
Just of note, this is also affecting the new Mozilla Firefox for U3 portable browser as well. Users are completely unable to, say, go to the Google website and install the toolbar.
We'd take a patch for this for 1.8.1 but not clear we are going to block on it.
(In reply to comment #20) > (In reply to comment #19) > > Is this bug still valid after all the extensions manager work lately? > > I was able to get extensions to install with the cache disabled within FF 1.0.7 > and 1.5b2. But at least once, I did run across this same message in 1.5b2 when > trying to install Sage from addons.mozilla.org. I clicked Install Now again > and it worked fine. I could not determine the reason. > WFM on this one yet?
(In reply to comment #24) > WFM on this one yet? Nope. It's still busted, though it doesn't happen all the time. I could install the Google toolbar and a couple extensions from addons.mozilla.org. But after whitelisting, I couldn't install prefbuttons from mozdev.org. (And yes, this is after whitelisting the locations). This is with 2.0 Final.
This has been working for me on Firefox 2/OS X for as long as I remember (perhaps as far back as April 2006), and I haven't seen any errors recently on my Linux workstation even though I keep caching turned off there too. I just tested by installing Adblock Plus, which worked perfectly. Is this still broken anywhere?
(In reply to comment #25) > (In reply to comment #24) > > WFM on this one yet? > > Nope. It's still busted, ... This is with 2.0 Final. > Should version then be updated to 2.0 branch?
Any confirmation that this is not working on any particular arch / OS / branch?
I'm gonna call this fixed.