Widevine components don't install if proxy is configured but not available

OS: macOs, High Sierra, 10.13.6 Version of electron-releases: 3.0.2-wvvmp

Use Case:

• A user has a proxy configured with a Proxy Configuration File, but the proxy becomes unreachable.
• In our application we have logic that sets the proxy settings for the electron application if it is configured AND available.
• If the proxy is configured and NOT available, the app runs without doing this extra work and runs as if the proxy isn’t there
• If the proxy is configured and NOT available, Widevine errors with the error code Error: net::ERR_MANDATORY_PROXY_CONFIGURATION_FAILED

Steps to reproduce

• Download the newest version of the application
• Open the terminal and clear out Library/Application\ Support/APP_NAME (rm -rf ~/Library/Application\ Support/APP_NAME)
• Open up the System Preferences -> Network -> Wi-Fi
• Ensure the lock in the lower left-hand corner is unlocked to make changes
• Click Advanced -> Proxies
• Check the Automatic Proxy Configuration box and put in a bogus URL (http://localhost:8080/foo.pac)
• Save/Apply the changes
• Install the application
• Open the application
  • EXPECTED: The application installs and loads the login page
  • ACTUAL: An error occurs, Error: net::ERR_MANDATORY_PROXY_CONFIGURATION_FAILED, and the application closes
• Close the application if it hasn’t closed already
• Remove the Automatic Proxy Configuration
• Open the application
  • EXPECTED/ACTUAL: The application loads the login page

Proposed solution:

• is it possible to have to opt into using the proxy for downloading the Widevine components, thus not using the proxy by default? Instead of defaulting to using the proxy and erroring if it is not available?

Hopefully all of this makes sense; if not, or if I am missing something, please let me know.

Relates to #31

[alexanderturinske]

Thank you so much! This looks great!

While you were working on this, I wrote of up guide for our clients on how to disable their proxy, install our application, and then re-enable; this temporary workaround seems to have placated several of our clients, but we definitely will want to upgrade to a version that supports this use case.

We are not stuck on 3.0.x; it is more that we just haven’t had the resources/reasons to upgrade…yet.

Thanks again; I will let you know how it goes.

Sorry for the late response; I was on PTO. 🍹

[khwaaj]

Closing due to inactivity, please reopen if you are still having issues.