User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; rv:1.7.3) Gecko/20040913 Firefox/0.10 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; rv:1.7.3) Gecko/20040913 Firefox/0.10 When you click the "Check Now" button under Software Updates, it fails if behind a proxy server. The work around is to go to a web page that requires the browser to log you into a proxy first. If you do this then go back and click "check Now" it works. Reproducible: Always Steps to Reproduce: 1. Open Firefox behind a proxy server that requires authentication 2. Click Tools, Options 3. Navigate down to Software Updates and click Check Now 4. Connection fails instantly Actual Results: Recieved an error message Expected Results: It should bring up the proxy authentication login box, and after sucessful username/password entered, check the update server and report results
Mozilla/5.0 (Windows; U; Windows NT 5.0; rv:1.7.3) Gecko/20040913 Firefox/0.10 This also applies to using the extension update functionality. To reproduce, change step 2 and 3: 2. Click Tools, Extensions 3. Select an Extension, and click Update
(In reply to comment #0) > When you click the "Check Now" button under Software Updates, it fails if behind > a proxy server. The work around is to go to a web page that requires the browser > to log you into a proxy first. I also saw this bug while attempting to upgrade some kiosk-type computers I manage that use the "AutoHide" extension on an intranet to 1.0PR (from 0.9.3). On the first run it asked me to run software update to update that extension, but it failed. I tried the above workaround and got it to work when running software update manually. This could be a big issue for seamless upgrades in a corporate environment. Mozilla/5.0 (Windows; U; Windows NT 5.0; rv:1.7.3) Gecko/20040913 Firefox/0.10
*** Bug 266673 has been marked as a duplicate of this bug. ***
Confirming. This is a big problem for all company intranets using password-protected proxies: The worst case scenario is that Firefox won't ever be updated, because users are not aware of this bug and don't know how to trigger the update manually... Since this prevents us from deploying security updates, setting severity to Major.
dveditz, do you have any idea what causes this bug? Darin said "most likely the networking layer is not being supplied with a nsIAuthPrompt to use"... Perhaps you could have a quick look at this. If a fix is easy, it could make Firefox 1.0 much more usable in corporate environments...
Saw also this bug on Firefox (up to 1.0RC1) in a managed Windows domain (proxy.pac,...) with a very susceptible Squid proxy (doesn't allow to go to a website if the url is not complete : especially if missing the first "www.". can lock dead firefox for a minute!) Even once authentified, the update agent cannot access to extension, themes and browser upgrade list. Very annoying.
no patch in sight, not gonna happen for 1.0.
*** Bug 268071 has been marked as a duplicate of this bug. ***
https://bugzilla.mozilla.org/show_bug.cgi?id=260476 This bug might be a duplicate of this. It was repored by me.
13 years ago
The problem is that (as best as I can describe it), every consumer of necko needs to implement the proxy auth UI support. People want to call Necko and make it all the work, but necko does not do this UI for various technical reasons. Everytime someone adds a network function, they always seem to forget this. it has happened so many times before, I can't remember the modules that had this problem, except, oh yeah, Netscape Activation (because it crashed everytime a 407 came back).
(In reply to comment #10) > The problem is that (as best as I can describe it), every consumer of necko > needs to implement the proxy auth UI support. benc, can you provide any pointers on how to find the piece of code where this bug could be fixed, e.g. which interfaces/methods are involved?
Asking for blocking-aviary1.1, because 1.1 is categorized as a bugfixing/polishing release, and should probably fix those bugs that are mentioned in the 1.0 release notes.
Extensions will not install, I ahve checke the 'Too' 'Web' presferences, and the option to allow sites to install software is enabeled. Any ideas will be helpful.
This bug also happens if there´s an extension that requires a connection like Gmail Notifier.
12 years ago
Regardles to this bug, you can still using software update. First open any webpage and authorize the proxy, and then run the update feature.
This happens also without password auth, but not in all cases, first time I seen this bug in 1.0.3, thunderbird 1.0.2 has the same bug
*** Bug 290944 has been marked as a duplicate of this bug. ***
->darin for triage.
I think this will still be an issue with the new update system. We don't exactly want to prompt users when we auto-update, but we do want to prompt them when they explicitly invoke the update system.
This is definitely something that we'd like to see in terms of ensuring we have a strong enterprise feature set. The workaround is clunky. Deferring for 1.8b4, need to revisit and determine action plan and assign resources for 1.5 or 2.0. /cb
Created attachment 192413 [details] [diff] [review] v1 patch
Comment on attachment 192413 [details] [diff] [review] v1 patch + var prompt = + Components.classes["@mozilla.org/network/default-auth-prompt;1"]. + createInstance(); + return prompt.QueryInterface(iid); could write this: return Components.classes["@mozilla.org/network/default-auth-prompt;1"]. createInstance(iid); either way, r=biesi
Comment on attachment 192413 [details] [diff] [review] v1 patch Yeah, I considered writing the more compact form as well. I preferred this way for readability, but maybe the 'tighter' code is better. Anyways, this is a pretty trivial and low-risk fix that would be nice to get in before we branch.
Is this fixed in Firefox 2.0? The comment says it's only fixed on the trunk, but the keyword says fixed1.8. :-s There is a similar issue (bug 268071) that was duped to this one that certainly isn't fixed in Firefox 2.0.
Sorry, the chain of dupes here suggests nobody really understands what's going on. I think the fix for each of them will be similar, but I doubt fixing one automatically fixes the other. I think there are four separate issues: 1. Software Update doesn't work if proxy requires authentication and not already authenticated Bug 259429 (This one, should be fixed in Firefox 2.0 as far as I can tell) 2. Extension Update doesn't work if proxy requires authentication and not already authenticated (e.g. at startup before main window is shown) Bug 359940 (wrongly DUPED to 312473), Bug 268071 (wrongly DUPED to 259429) Could be two cases: - Before main window is shown - After main window is shown but before user has authenticated to the proxy 3. Extension Update doesn't work if target link requires HTTP authentication Bug 312473 4. Live bookmarks don't work if proxy requires authentication and not already authenticated (e.g. if home page is about:blank) Bug 260476 Can somebody sort this mess out? I propose: - Reopen 268071 - Redupe 3559940 to 268071 - Not adding any further spam to 259429 :-)