Open Bug 799861 Opened 12 years ago Updated 2 years ago

Stub installer does not detect proxy (Win7)

Categories

(Firefox :: Installer, enhancement, P3)

18 Branch
x86_64
Windows 7
enhancement

Tracking

()

People

(Reporter: spinus1, Unassigned)

References

Details

(Whiteboard: [stubv3-][fce-active-legacy])

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/18.0 Firefox/18.0
Build ID: 20121009042010

Steps to reproduce:

I've downloaded stub installer from http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-aurora/firefox-18.0a2.en-US.win32.installer-stub.exe

I've started the installer and go on with the installation


Actual results:

It stuck on "Downloading" phase, I cannot see any activity on network...so I think it simply does not connect using the PAC autoconfiguration url that is set on  Windows
Component: Untriaged → Installer
Keywords: qawanted
QA Contact: jsmith
Calling non-blocking until I hear more reports on this or confirm the behavior. If I confirm it, I'll re-evaluate the blocking flag.
Whiteboard: [stub-]
QA Contact: jsmith
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: qawanted
There was a rewrite of the networking code recently. Could you please confirm this is still a problem with the stub installer? Thanks!
Flags: needinfo?(spinus1)
If the rewritten networking code is released already, then it still does not work - I downloaded version 22 stub and it behaved the same way as described in the opening post.

Note that my proxy also requires proxy authentication if this would be a problem. Also note that after I downloaded full installation package by other means and installed Firefox, Firefox was able to detect the proxy settings correctly.
Flags: needinfo?(spinus1)
Confirmed stub installer still does not detect proxy settings in Win7 32-bit (basic authentication proxy).

Tested: ftp://ftp.mozilla.org/pub/firefox/releases/22.0/win32/en-US/Firefox%20Setup%20Stub%2022.0.exe
Whiteboard: [stub-] → [stubv2-]
Whiteboard: [stubv2-] → [stubv3-]
The same issue is seen with Firefox Developer Edition.
Windows 7, 32-bit. Corporate http proxy.
After launching the stub "firefox-40.0a2.en-US.win32.installer-stub.exe", it does not prompt for proxy credentials and keeps showing that it is downloading.

Unfortunately, there is no means of downloading the "full" version of Firefox Developer Edition. Even https://www.mozilla.org/en-US/firefox/developer/all/ provides a stub and no offline installer.
While you fix the bug I need to work around the problem.

The installer does try to use the proxy or ignores the proxy completly?

What is the file link were the file is being downloaded?

If the installer is trying to use the proxy I can add the site to my whitelist list so it pass through the proxy without providing authentication values.
If it goes through a non standard port also need the port to add it to the Squid safe ports.

If the installer is ignoring the proxy I need the exact link to included in my "Allowed Hostnames" in my Captive Portal.

With this info we can wait for the bug to be fixed or even consider it solved.
Ignoring, 4+ years, it's a joke.
I do not consider the use of the full installer the best work around.

I really would prefer to know which is the firefox real download link to the installer to use it in my Squid allow sites or to add it to my captive portal allowed hostnames.

Having to download the full version is an additional task for the IT people and having to explain a mad user the problem.  The user maybe intelligent enough to do it by themselves but still his going to be mad.
(In reply to Jose Torres from comment #11)
> I do not consider the use of the full installer the best work around.
> 
> I really would prefer to know which is the firefox real download link to the
> installer to use it in my Squid allow sites or to add it to my captive
> portal allowed hostnames.
> 
> Having to download the full version is an additional task for the IT people
> and having to explain a mad user the problem.  The user maybe intelligent
> enough to do it by themselves but still his going to be mad.

Why is the full installer not a sufficient workaround? It's unclear if your users are not permitted to do it by themselves or if you just don't want them to.

Preliminarily, as this is a very old bug, can you confirm that you're dealing with Win7?
Flags: needinfo?(jetberrocal)
Priority: -- → P3
Whiteboard: [stubv3-] → [stubv3-][fce-active]
Users are permitted to download the full file but they require IT assistance as they have non technical knowledge.  Thus having to download the full file is a burden to me, but when they have the knowledge still goes against me as they will expect the stub to work.  The stub sits there a very very long time before going to error, wasting the user time and clearly making them mad at IT.

Yes, the currently used OS by most of the users is Win 7.
Flags: needinfo?(jetberrocal)
I do not expect the bug to be fixed, but to receive the information needed for squid or captive portal to allow pass through.
(In reply to Jose Torres from comment #14)
> I do not expect the bug to be fixed, but to receive the information needed
> for squid or captive portal to allow pass through.

The URL that the stub installer requests is:
http://download.mozilla.org/?os=win&lang=en-US&product=firefox-latest
where the locale can be set to whatever is appropriate.
The server that handles that request redirects it to something like
http://download.cdn.mozilla.net/pub/firefox/releases/50.1.0/win32/en-US/Firefox%20Setup%2050.1.0.exe
which is the final download location. I'm not sure how stable that URL is; it could change without warning.

Hopefully that's the information you were after; let me know if you need something more.
Thank you for your answer.  Kind of late, but better than no answer at all.  At least this will benefit others.

Yes this information suffice what is needed for Squid and Captive Portals.  One will add the two addresses to the whitelist of the Proxy or Firewall.  I still do not know if the installer will use the proxy or not, but one could find out by trial and error.  Probably is not using the proxy because the logs would have reveal it.
Severity: normal → enhancement
(In reply to Robert Strong [:rstrong] (use needinfo to contact me) from comment #10)
> The workaround is to use the full installer.
> https://www.mozilla.org/en-US/firefox/all/
> or
> https://www.mozilla.org/en-US/firefox/installer-help/
> ?channel=release&installer_lang=en-US

Yes, but the full installer is well hidden on the Firefox download page so that Joe Average won't find it.
Which means that he'll download Chrome instead. ;-)
(In reply to Olaf from comment #19)

> Yes, but the full installer is well hidden on the Firefox download page so
> that Joe Average won't find it.
> Which means that he'll download Chrome instead. ;-)

It looks like the 32 and 64 bit links on the modal displayed when selecting "Advanced install options & other platforms" on https://www.mozilla.org/en-US/firefox/new/ point to the stub when they should be pointing to full installers. I just raised this on https://bugzilla.mozilla.org/show_bug.cgi?id=1386622#c38
Whiteboard: [stubv3-][fce-active] → [stubv3-][fce-active-legacy]
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.