Unresponsive PAC URL = FoxyProxy completely locks up

Hi,

The last two days my usual authenticated proxy provider (from university) has had some serious problems with their services, including the authenticated proxy service (those problems have been worked out in the meantime).

I've had the proxy configurated on FoxyProxy through the PAC they provide, and during the downtime mentioned earlier, FoxyProxy completely locked up, preventing me from using Firefox in the first place (both the stable 3.0 version in Windows XP 32-bit and Ubuntu 9.04 64-bit, and the 3.5 beta 4 version on the same OSes).

Unfortunately I haven't managed to get any kind of usable logs (my priority was to have a functional browser anyway) and the problem was "fixed" by removing the .xml configuration file for the plugin.

I currently don't have any tool to simulate an unresponsive server and try to replicate the situation, but what apparently caused it was trying to get the PAC from a server with a really long response time (> 20 seconds until it timed out), which caused FoxyProxy to completely lock-up the browser. Running a profile where the plugin wasn't loaded worked fine.

If there is any other info I can provide, just say it.

Best regards,

João Neves

Hi João, Thanks for the

Hi João,

Thanks for the report. This makes sense. If FoxyProxy can't determine all rules to load pages (including downloading PAC files), it will prevent Firefox from loading everything. You can think of this as a security measure in a sense. For example, let's say Firefox was permitted to continue even though the PAC couldn't load. How should it behave? How should URLs load?

Another option is to host the PAC file locally on your PC's hard drive instead of remotely. Let me know if you want more info about this.

By deleting foxyproxy.xml, you removed the dependency on the PAC file.

Ideally, Firefox shouldn't freeze, but it also shouldn't load URLs normally. I'm open to ideas / suggestions for alternative behavior.

Thank you again,
Eric

Hi Eric, Thanks for the

Hi Eric,

Thanks for the reply!

I probably see a couple of alternatives you might want to consider:

1) If the PAC couldn't be loaded, two situations can occur:
1.a) If the PAC is configured on a proxy to be used on all URLs, you could display a message box with something like: "The PAC for proxy X could not be loaded. This means the proxy will be inactive during this session, do you want to continue? Yes/No". Selecting "No" would probably close the browser or something (I'm not much into addon development, so I don't know if addons have permissions for this).

1.b) If on the other hand the PAC is configured on a proxy with a given set of whitelisted URLs you could let the browser function normally, and when the user hit a URL that matched one of the whitelisted ones you could pop-up a message box warning the PAC couldn't be loaded so the proxy won't function, like in the previous case, but this time a "No" would just mean the page wouldn't be loaded (probably displaying an alternative page in the corresponding tab). Possibly giving the user the chance to "remember" this behavior for that session so you'd display the alternative page for each matching URL on that proxy.

2) Just warn the user, let the browser proceed normally.

3) Do nothing. (Not good for the reasons you pointed out.)

From my point of view, solution 1 would probably be the best, since it prevents the user from visiting webpages without the required proxy but would ideally allow the browser to be usable anyway for the remainder of the pages (or all of them, if the user so wishes).

Alternatively (and probably much more simply) you could automatically cache the PAC every time it's successfully loaded, and if for some reason you can't load it remotely you can just use the cached version.

Mind you, these are a bit out of the top of my head, so I may haven't seen something terribly wrong with these alternatives.

All in all, I simply feel the current behavior (locking up the browser in a way it's completely unusable) is just not the way it should work.

Thanks once again for the reply, if you so wish I'd be glad to further discuss some way of working this out.

Best regards,

João Neves

Thanks for the ideas. I will

Thanks for the ideas. I will probably do #2 first because it is much simpler than #1. I'll get to it as soon as possible.

Eric

Awesome, thanks! João

Awesome, thanks!

João