Slow/weird network requests

[Lombra]

• Electron Version: 3.0.0 beta 3
• Operating System (Platform and Version): Windows 7 64 bit
• Last known working Electron version: 2.0.5

I'm doing HTTP requests using fetch from my application to a server running on the same machine, and starting with 3.0.0 beta 1 these take several seconds to complete. For testing I've just typed in the following in the console:
fetch('http://192.168.0.202:32155/api/panels').then(console.log)
When I do one at a time it seems to consistently take 2.5 seconds. When I queue up several requests without waiting for a response they seem to get processed one after another or something. Looks like this in the console:

All the time seems to be alotted to stalling and proxy negotiation.

I don't know what to make of that. I don't have any special proxy configuration.

In contrast, on version 2.0.5 it looks like this:

Requests using XMLHttpRequest and net.request from the main process seems to behave in the same way. As far as the server is concerned all the requests finish in <1 ms.

I'm developing my application on Electron 1.7.6 currently, where I've never experienced this issue either. Planning to upgrade to 3.0.

I'm not passing any command line arguments, nor does it seem to be affected by any of my code. I had the same both in my application and a barebones one I made for testing with an empty index.html.

const electron = require('electron')
electron.app.on('ready', () => {
	let win = new electron.BrowserWindow()
	win.loadFile("index.html")
})

[MarshallOfSound]

cc @deepak1556 proxy stuff 🤔

[Lombra]

I have some new info. Besides my regular network adapter I also have a VirtualBox host only adapter. Disabling this brings response times down to expected levels. Specifying my "real" adapter as the listening interface for the server does not help.

[GhostlyDark]

My app uses a local server for displaying content. The first startup of the app after booting up the machine takes longer than expected. The same happens after a long time not using the app (idling or simply having it closed for an hour or so).

Deactivating my VMWare network adapters reduces this first startup time by a couple of seconds.
None of this happens with v2.0.x
Running Windows 10 x64

[ghost]

There is some evidence that suggests this may be related to the version of Windows you're running. Windows 10 doesn't seem to repro, but Windows 7 does.

[Darxide23]

Hi folks. I reported the problem on IAmPicard's app after his update which included an upgrade to Electron 3.0. It loaded incredibly slow, but upon disabling my VirtualBox network interface all problems were instantly resolved. It seems the Windows version was a red herring and shouldn't matter.

EDIT: I'll post here what I posted in the other bug report. I'm on Win7 SP1 and have three active network interfaces. My main interface to my router, a VirtualBox interface, and an interface for my VPN. If I disable the VirtualBox interface then the problem immediately resolves itself. The VPN interface appears to have no impact at all so the problem looks to be specifically the VirtualBox interface.

[deepak1556]

Hi! it would be great if anyone can attach the output file of --log-net-log switch, when used along with your app.

app.exe --log-net-log=netlog.json

Make sure make the problematic requests in question before closing the app. Also if you are using some additional network related command line flags with your app, can you please include them with your report. Thanks!

[Lombra]

net-log.txt

No additional command line flags.

I noticed that passing --no-proxy-server seems to be another workaround though, in case that helps.

[GhostlyDark]

netlog.txt

Passed --enable-sandbox, which shouldn't make a difference.

Captured within a VMWare Virtual Machine running Windows 7 32-bit. Deactivating the network adapter within the VM fixes the issue.

@Lombra Thanks for the workaround. This will come in very handy.

[deepak1556]

@Lombra @GhostlyDark thanks for the log, I was able to confirm the issue. We switched to use the system proxy resolver in 3.x, which seems to have problems with proxy auto-detect settings. I will look into fixing this. Can you confirm if disabling proxy auto-detect solves this ? Can also check if disabling auto-detect and specifying a explicit PAC url http://wpad/wpad.dat which essentially disables DHCP based wpad solves the issue ?

[GhostlyDark]

Disabling auto-detect fixes the issue.
Disabling auto-detect and specifying http://wpad/wpad.dat or http://wpad.example.com/wpad.dat as configuration adress does not fix the issue.

I changed the LAN settings of inetcpl.cpl, so I hope I got this right.

[deepak1556]

@GhostlyDark thanks, that helps. We will have to move away from the system proxy resolver to fix this, the resolver timeout is expected in this case as per the implementation under auto detect https://cs.chromium.org/chromium/src/docs/proxy_auto_config.md.

[happypoulp]

Hi,

Can someone confirm that fixes for this issue will be merged soon in an upcoming 3.0.x release?

Thanks!

[lauracpierre]

Same please!
I see the commit being merged on October 24 but see nothing in the commit list from 3-0-x: https://github.com/electron/electron/commits/3-0-x

Could get that merged urgently with a new release please? This is impacting a lot of users on Windows 7 mainly.

Happy to help in any way I can to make this happen :)

[lauracpierre]

Meanwhile, since downgrading to 2-0-x was not an option for us, I disabled some of the flags previous comments mentioned ☝️

Not sure which one made it work, but the following two lines fixed it for us (hard to know which one because I never reproduced the error, only some customers did):

app.commandLine.appendSwitch('auto-detect', 'false')
app.commandLine.appendSwitch('no-proxy-server')

Hope this will save time for some people.

[Darxide23]

--no-proxy-server

That's all I've used as options in the program shortcut and it works.

[deepak1556]

The issue was fixed in #14656 which landed in 4.x branches and above. Due to the volume of refactor we are unsure about backporting to 3.x (stabilized branch) at this point. I would recommend updating the apps to 4.x or use one of the workarounds mentioned here. Thanks!

[jakubzitny]

Just to add more info on this. Our customers had similar problems as @lauracpierre, the switches helped to fix it for them, we couldn't really replicate the problems either.

Is there any ETA on v4 release @deepak1556, please?

[deepak1556]

@jakubzitny we are predicting to release 4.0 stable sometime in December, but you can test with one of the 4.0 beta releases from https://electronjs.org/releases now. Thanks!

[oopets]

Hi,
"--no-proxy-server" seems to fix the issue for us (tested by installing VirtualBox network adapter on Windows 7 and checking how the electron app works)
@deepak1556 Do you think "--no-proxy-server" flag can break internet connectivity for some users or it can be used safely?

[lauracpierre]

It can break connectivity, this was reported to me by some users.
Looking for another solution today

@deepak1556 Waiting for 4.0 stable release is difficult. 3.0.x were already not so stable (connectivity issues, print issues, etc)

[petrbrzek]

@lauracpierre What did you end up with?

[lauracpierre]

So far there is no ideal solution.
We can either have two builds of the same app (but it's not scalable) or add an option in a menu to enable/disable this option. (the option can be stored in a local preference and the app can check this preference at launch.

:/

(I do not understand the vision behind working on version 4 while version 3 is still at this stage.)

[DBnR1]

Extremely unfortunate bug. We'll have to revert back to 2.x for the time being.

[deepak1556]

At the moment I can't guarantee immediate backport to 3.x release line, #14656 is not a trivial change to be backported into a stable release line and also because of the build system difference between master and 3.x. But would be glad to guide anyone willing to backport it.

[deepak1556]

Backport for 3.x is available now #15813

[deepak1556]

v3.1.0-beta.1 has the fix, can you try it out and update the issue. Thanks!

[Lombra]

I hadn't even tried 4.0 yet, but 3.1.0 fixes this, indeed.

[mvdicarlo]

I am having some users report that this problem or some variation is still occurring on 4.0.1.
Their network logs just show Failed to load resource: net::ERR_TIMED_OUT for any website hit.

Personally able to reproduce the issue. None of the mentioned flags seems to resolve the problem either.

[Lombra]

Not related. This issue was not about network requests failing.

[GlassGruber]

I don't know if this can be of any help, but this very same fix of --no-proxy-server is also used for very similar issues for Puppetter / Headless Chrome:
codeceptjs/CodeceptJS#561
puppeteer/puppeteer#2391
puppeteer/puppeteer#1718

[marco-ms]

@Lombra I know this has been fixed, but is there a way to understand how to detect this bug?
To me is unclear the following:

1. Does it affect users under a proxy or all Winodows 7 users?
2. Does it affect localhost requests or all of them?
3. From a net log, how you detect this problem is happening?

[GhostlyDark]

@marco-ms

1. As far as my testing goes, any Windows 7 user having some kind of additional network adapter installed, like VMWare or VirtualBox and anybody running Windows 7 within such virtualisation software. Disabling the proxy avoids the issue.
2. All of them.

[marco-ms]

@Lombra that means to reproduce you need to run Electron 3.0 on a Windows 7 virtualized or you can reproduce also on a Windows 7 host machine where VirtualBox/VMWare has been installed but isn't running?
Do you have an answer for Q.3? How this issue is detectable?

Thanks!

[Lombra]

@marco-ms It is not limited to Windows 7 I don't think. I reproduced it on a physical machine. As for the net log, you'd have to ask @deepak1556.