search

brave / brave-browser

Brave browser for Android, iOS, Linux, macOS, Windows.
https://brave.com
Mozilla Public License 2.0
17.54k stars 2.27k forks source link

"Upgrade connections to HTTPS" (aka HTTPS Everywhere) causes significant page load delay #6196

Open JessePeden opened 4 years ago

JessePeden commented 4 years ago

Description

Since the last few public full releases (not nightly or dev builds), there has been an issue with page loading being stuck in the "processing request" phase for extremely long periods of time (roughly 30 seconds) before finally displaying a page. After a bit of troubleshooting, I have found the cause is the "Upgrade connections to HTTPS" option (aka. HTTPS Everywhere). It happens if you use either the built-in option or the official HTTPS Everywhere plugin, so I'm not sure which is really to blame (the browser for its implementation or the rulebase EFF). It seems to be limited to sites that automatically redirect from HTTP to HTTPS on their own anyway (without the need for a conversion in the browser or via plugin. If you go directly to the HTTPS version of these sites, there is no delay at all. If you disable the plugin or the feature to redirect from HTTP to HTTPS (leaving it to the site itself to redirect users) there is no delay at all.

Steps to Reproduce

  1. Enable "Upgrade connections to HTTPS" or have the HTTPS Everywhere plugin installed/enabled
  2. Browse to a site that redirects from HTTP to HTTPS anyway (i.e., http://spotify.com)
  3. Notice the delay in page loading

Actual result:

Roughly 30 seconds delay in page loading while the site switches from HTTP to HTTPS.

Expected result:

No delay in redirecting users from HTTP to HTTPS

Reproduces how often:

100% reproducible

Brave version (brave://version info)

Brave 0.68.141 Chromium: 77.0.3865.90 (Official Build) (64-bit)
Revision 58c425ba843df2918d9d4b409331972646c393dd-refs/branch-heads/3865@{#830}
OS Windows 10 OS Version 1903 (Build 18362.387)
Brave 0.68.142 Chromium: 77.0.3865.90 (Official Build) (64-bit)
Revision 58c425ba843df2918d9d4b409331972646c393dd-refs/branch-heads/3865@{#830}
OS Windows 10 OS Version 1903 (Build 18362.387)
Brave 0.69.132 Chromium: 77.0.3865.90 (Official Build) (64-bit)
Revision 58c425ba843df2918d9d4b409331972646c393dd-refs/branch-heads/3865@{#830}
OS Windows 10 OS Version 1903 (Build 18362.388)
Brave 0.70.121 Chromium: 78.0.3904.70 (Official Build) (64-bit)
Revision edb9c9f3de0247fd912a77b7f6cae7447f6d3ad5-refs/branch-heads/3904@{#800}
OS Windows 10 OS Version 1903 (Build 18362.418)

Version/Channel Information:

Other Additional Information:

Miscellaneous Information:

JessePeden commented 4 years ago

This appears to be fixed in the 0.68.142 release (it was present in the 0.68.141 release), though the release notes mention nothing about this issue or anything related to it being addressed.

This is still present in 0.68.142 after some more testing, though it seems mildly less prevalent. For example, I could previously get it to trigger on http://spotify.com but that appears to be working properly each time I tested. I can still get it to trigger on other sites, such as http://yahoo.com.

JessePeden commented 4 years ago

This is still present in 0.69.132.

bsclifton commented 4 years ago

@diracdeltas any tips for debugging?

JessePeden commented 4 years ago

@bsclifton @diracdeltas The strangest part about this issue is that it doesn't happen on ALL sites that redirect from HTTP to HTTPS - only some. For example, going to sites like wholefoods.com redirects immediately from HTTP to HTTPS, but other sites like nytimes.com has a significant delay before redirecting. The delay goes away as soon as you disable the HTTPS Upgrade feature (and clear cache/history), then try again. Also, I have not been able to recreate the issues in the macOS or Android builds, so it seems isolated to the Windows build. The macOS and Windows setups are set identically, with the same extensions and such in them, for the record.

rebron commented 4 years ago

cc: @AndriusA @too4words can you guys take a look?

JessePeden commented 4 years ago

This still happens in 0.70.121. I just tested yahoo.com, nytimes.com, and bing.com. All of them hung for over a minute before loading, with HTTPS Everywhere enabled. As soon as I disabled it and tried again, they load almost instantly.

AndriusA commented 4 years ago

@sybercorp that does indeed sound very strange, I've checked with both macOS and Windows 10 (beta and current stable 0.70.121), explicitly specifying http:// and https:// for the three sites and still failing to reproduce...

Is there anything on your network that might be intercepting HTTPS traffic?

JessePeden commented 4 years ago

@AndriusA It's network agnostic (I can recreate it no matter where I am). And, no, if that were the case, it wouldn't work at all when I went to HTTPS sites. The problem is that the HTTPS Everywhere (Upgrade Connections to HTTPS) feature is interfering with the redirection/URL-rewrite from HTTP to HTTPS for certain sites (which makes some sense since HTTPS Everywhere works on a rulebase for specific sites, not just globally for all sites). I'll record my screen then upload the video to YouTube, to show you all what it looks like with HTTPS Everywhere enabled versus disabled.

Here are the links to the videos I made.

Broken (HTTPS Everywhere enabled): https://youtu.be/-xsgNWqu55o Working (HTTPS Everywhere disabled): https://youtu.be/Ko_ooDZPWmg

JessePeden commented 4 years ago

Is anyone going to offer any help with this? Most sites redirect from HTTP to HTTPS on their own, so leaving HTTPS Everywhere disabled isn't really too big of a deal these days, but there's still a bug and I provided videos as proof to help you guys. To date, I see there have been 0 views of those videos I provided, which is disheartening since you have only said you were unable to recreate the issue and see it in action, so I made the videos to show you the issue in action.

JessePeden commented 4 years ago

@rebron Does you removing this from Untriaged Backlog mean that you aren't going to fix this at all?

jonathansampson commented 4 years ago

@sybercorp Sorry for the radio-silence; would you be able to run a few more tests for me?

  1. Open a Guest Window and see how long the navigation takes
  2. If possible, connect to a mobile hotspot (or another network) and see if this has any effect

Please do let us know what results you find.

JessePeden commented 4 years ago

@jonathansampson

  1. I don't have Windows installed any longer, so I can't test that.
  2. I tried that as part of what I mentioned before (in https://github.com/brave/brave-browser/issues/6196#issuecomment-546508853), that it doesn't matter which network I'm connected to.
jonathansampson commented 4 years ago

@sybercorp Was this issue only happening on Windows? If not, we can test on Linux/macOS as well. Do you run any type of antivirus software in parallel and/or VPN software on the device?

JessePeden commented 4 years ago

@sybercorp Was this issue only happening on Windows? If not, we can test on Linux/macOS as well. Do you run any type of antivirus software in parallel and/or VPN software on the device?

@jonathansampson Yes it was isolated to Windows (see my previous comment https://github.com/brave/brave-browser/issues/6196#issuecomment-540020246).

There is VPN software installed but whether it was in use or not had no bearing on the issue.

AV was installed but had none of its browser or network detection modules enabled or installed.

jonathansampson commented 4 years ago

@sybercorp Thank you for the prompt response! Unfortunately, I don't believe we have a clear test path now that you are no longer on Windows. I will keep my eyes and ears open for similar reports from other users, and merge with this if/when they arise. Thank you again for the feedback, and please do let us know if there is anything further we can do for you.