Closed Bug 1366772 Opened 3 years ago Closed 2 months ago

Proxy Auto Config file not checked when network is changed


(Core :: Networking: HTTP, defect, P2)

53 Branch





(Reporter: thetfordb, Unassigned, NeedInfo)



(Whiteboard: [necko-active][proxy])

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:53.0) Gecko/20100101 Firefox/53.0
Build ID: 20170504105526

Steps to reproduce:

I've configured my system with a PAC file that will route traffic through our proxy when they are not connected to our internal network.  Firefox is set to use the system settings for the network connection method.  The configuration works well except when Firefox is left open during a network change.  (switching between our corporate Wi-Fi and a hotspot).  I'm on a macOS 10.12.5 device.  I attempted this on Windows 7 and everything worked as expected.  It seems to be isolated to the macOS version.

Actual results:

Traffic is not routed through our proxy and the traffic is allowed to websites that should be disallowed.  If I close Firefox and then reopen, the traffic is properly routed through our proxy.

Expected results:

Traffic should be routed through our proxy and disallowed to websites that should be disallowed.  

Safari and Chrome all function as expected.  I do not have to close these browsers to have it function.
Component: Untriaged → Networking: HTTP
Product: Firefox → Core
OS: Unspecified → Mac OS X
Assignee: nobody → daniel
Whiteboard: [necko-active]
Whiteboard: [necko-active] → [necko-active][proxy]

@work I am 
 * on Windows 7 Pro 64 bits
 * Firefox up to date
 * also a proxy.pac (from "Use System proxy setting")

and if I switch from LAN to Wifi, or if I activate a VPN to a lab or to another, I have to stop Firefox and launch it again to be able to browse again.
I'm not able to reproduce this, details:

- Windows 10 Pro x64
- Firefox 54.0 64-bit
- Use system proxy PAC setting
  - DIRECT on LAN or PROXY otherwise

then switch between company wired network and Wi-Fi network for guests.
Reproduced today: Windows 7, Firefox 54.0 64bits

Was on Ethernet
Had to change Network for another project
Unswitched Ethernet
Switched ON Wifi
Launched VPN
Tried to browse in Firefox -> *fail*

Stop Firefox, launched it again => OK
Bulk priority update:
Priority: -- → P1
So we've seen this on Windows and OSX:  we should try harder to reproduce.  Daniel, try it yourself and/or recruit other folks.  This is worth fixing (though not for 57, hence P2).
Flags: needinfo?(daniel)
Priority: P1 → P2
Ever confirmed: true
Assignee: daniel → nobody
Flags: needinfo?(daniel)
Honza -- can you have a look please?
Assignee: nobody → honzab.moz
Flags: needinfo?(honzab.moz)
Comment 0, 1 and 3 are not fully clear to me.  Looks like the PAC file was setup in the system (on Win10 under Internet Options/Connections/LAN Settings/Use automatic configuration script + Address).  The default setting for Fx is to ask the system for a proxy.  I don't see a link to network change here.

I can try to reproduce, but not sure when I get to this.
Flags: needinfo?(honzab.moz)
I sent a PI request to try to find steps to reproduce.
Based on the PI request received for this issue, we proceeded into investigating and trying to reproduce this bug.
To start with, Softvision network is a bit unsuited for this kind of investigation due to the fact that the main network is secured and the routers have Proxy-Access HTTP proxy denied from the rooter Application Control. However, we do have a secondary test network which we managed to adjust in order to use it. The problem with the secondary network is that only two isolated machines (2x desktops) are in it. Since they are desktops, there is no possibility to switch between networks, so the results on that side were inconsistent. 

We have managed though to use a Windows 7 laptop with the latest Nightly build (20181029173531)  with two wireless connections to phone hotspots using a system wide simple pac ("Use System proxy setting") as follows (pac was locally hosted: file://C:/proxy.pac):

function FindProxyForURL(url, host) {return "PROXY; PROXY;";}

Both proxies are valid proxies and switching between wireless networks did not provide reproducing results. 

In the next few days, a new laptop, set up for the secondary test network will be available for a different PI and we can probably follow-up with additional investigation on that machine, including also older builds and tests on Osx. 

What could be interesting of noting is that bug 1513571 might be related to this one.
Flags: needinfo?(adrian.florinescu)
See Also: → 1513571
Following up the above with additional tests on Win7 x64 and Osx 10.13.6,  with the same results as above: could not reproduce the loss of connectivity on network switch.

Tested on ESR 60.4.0esr 20181204161535 , Release 64.0 20181206201918 and Nightly 66.0a 120181218095120

To reiterate a bit the test environment:
-system global pac file, which contain two functional proxies:  function FindProxyForURL(url, host) {return "PROXY; PROXY;";}
-for the way it was set on the system, I've tried with both a local "file://C:/proxy.pac" and also http://localhost/proxy.pac (using a python simple http server)

For emulating  switching betwen different networks, I've used several hotspots. 

Therefore, IMO, unless this issue requires a special type of environment or different steps than the STR that are hinted in the original reported scenarios, I would conclude that the issue is not reproducible on the latest versions. , Pascal BORSCHNECK , could you perhaps assist into reproducing this issue on any of the versions listed above? If sucessfully reproducing the issue, a network log would most likely help (about:networking#logging)
Flags: needinfo?(thetfordb)
Flags: needinfo?(borschneck)
Flags: needinfo?(adrian.florinescu)

Sorry, for me impossible as I moved from my previous job: no more proxy.pac for my browser now =)

About how I switched from network
 - was on LAN, Wifi Off
 - disconect LAN cable
 - activate Wifi (and/or VPN)

Firefox seems not re-read pwoxy.pac
Flags: needinfo?(borschneck)
I'll see if I can get more info next month.  We're a K12 organization and will be out until Jan 7th.

Candidate for RESOLVED/INCOMPLETE for lack of data.

Assignee: honzab.moz → nobody
Closed: 2 months ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.