Note: There are a few cases of duplicates in user autocompletion which are being worked on.

Cannot install extensions when Firefox's disk cache is disabled

RESOLVED WORKSFORME

Status

Core Graveyard
Installer: XPInstall Engine
--
major
RESOLVED WORKSFORME
13 years ago
2 years ago

People

(Reporter: John T. Haller (email is bugzilla2@), Unassigned)

Tracking

1.0 Branch
Dependency tree / graph
Bug Flags:
blocking-aviary1.0 -
blocking-aviary1.5 -
blocking1.8.1 -

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [asaP1], URL)

Attachments

(2 attachments)

(Reporter)

Description

13 years ago
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.

Comment 1

13 years ago
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/
(Reporter)

Comment 2

13 years ago
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).
Keywords: helpwanted
OS: Windows XP → All
Hardware: PC → All

Updated

13 years ago
Severity: normal → major
Setting blocking-aviary1.0 to ? to get a decision on whether this should block.
Flags: blocking-aviary1.0?

Comment 4

13 years ago
Darin, do you think this is a network issue?
Flags: blocking-aviary1.0? → blocking-aviary1.0-

Comment 5

13 years ago
This bug has already been reported as bug 259428.

Comment 6

13 years ago
*** Bug 259428 has been marked as a duplicate of this bug. ***

Comment 7

13 years ago
*** Bug 267636 has been marked as a duplicate of this bug. ***

Comment 8

13 years ago
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.

Comment 11

13 years ago
*** Bug 271119 has been marked as a duplicate of this bug. ***
Flags: blocking-aviary1.1?
Summary: Cannot click to install extensions from a webpage when Firefox's disk cache is disabled → Cannot install extensions when Firefox's disk cache is disabled
Component: Extension/Theme Manager → Installer: XPInstall Engine
Product: Firefox → Core
Version: unspecified → 1.0 Branch

Updated

13 years ago
Blocks: 286661
maybe caused by bug 126344
Depends on: 126344

Comment 13

13 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

Updated

13 years ago
Whiteboard: [asaP1]

Comment 15

13 years ago
*** 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.
Flags: blocking-aviary1.1? → blocking-aviary1.1-
QA Contact: bugs → benjamin

Comment 17

13 years ago
Hmm.. I'd recommend against the current patch unless we run out of time to fix
the real problem.

Updated

12 years ago
Blocks: 294999

Comment 18

12 years ago
*** Bug 300617 has been marked as a duplicate of this bug. ***

Comment 19

12 years ago
Is this bug still valid after all the extensions manager work lately?
(Reporter)

Comment 20

12 years ago
(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.
(Reporter)

Comment 21

12 years ago
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.
(Reporter)

Comment 22

12 years ago
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.

Updated

12 years ago
Flags: blocking1.8.1?

Comment 23

11 years ago
We'd take a patch for this for 1.8.1 but not clear we are going to block on it.
Flags: blocking1.8.1? → blocking1.8.1-

Comment 24

11 years ago
(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?
(Reporter)

Comment 25

11 years ago
(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.

Assignee: bugs → xpi-engine
QA Contact: benjamin

Comment 26

10 years ago
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?

Comment 27

10 years ago
(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?

Updated

9 years ago
Assignee: xpi-engine → nobody
QA Contact: xpi-engine
Duplicate of this bug: 275607

Comment 29

8 years ago
Any confirmation that this is not working on any particular arch / OS / branch?
I'm gonna call this fixed.
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Keywords: helpwanted
Resolution: --- → WORKSFORME
(Assignee)

Updated

2 years ago
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.