259429 - Proxy: Software Update does not request authentication and fails

Status: RESOLVED FIXED

(Toolkit :: Application Update, defect)

Description

[Anthony Bongaards]

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

Comment 1

[Matt Ryall]

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

Comment 2

[Tom Hessman]

(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

Comment 3

[Frank Wein [:mcsmurf]]

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

Comment 4

[Jens Bannmann]

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.

Comment 5

[Jens Bannmann]

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...

Comment 6

[Xavier Mouton-Dubosc]

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.

Comment 7

[Asa Dotzler [:asa]]

no patch in sight, not gonna happen for 1.0. 

Comment 8

[Phil Ringnalda (:philor)]

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

Comment 9

[Praveen Tirumandyam]

https://bugzilla.mozilla.org/show_bug.cgi?id=260476

This bug might be a duplicate of this. It was repored by me.

Comment 10

[benc]

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).

Comment 11

[Jens Bannmann]

(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?

Comment 12

[Jens Bannmann]

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.

Comment 13

[dneverson]

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.

Comment 14

[Javier]

This bug also happens if there´s an extension that requires a connection like
Gmail Notifier.

Comment 15

[William]

Regardles to this bug, you can still using software update. First open any webpage 
and authorize the proxy, and then run the update feature.

Comment 16

[Gianluigi Tiesi]

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

Comment 17

[José Jeria]

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

Comment 18

[Asa Dotzler [:asa]]

->darin for triage.

Comment 19

[Darin Fisher]

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.

Comment 20

[Chris Beard]

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

Comment 21

[Darin Fisher]

Attachment: v1 patch

Comment 22

[Christian :Biesinger (don't email me, ping me on IRC)]

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 23

[Darin Fisher]

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.

Comment 24

[Darin Fisher]

fixed-on-trunk

Comment 25

[Mikel Ward]

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.

Comment 26

[Mikel Ward]

I think that bug 268071 should have been duped to bug 312473 instead.  Agree?

Comment 27

[Mikel Ward]

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 :-)