Bug #160
closedSites won’t load if a domain user agent is set that is different than the current user agent.
0%
Description
For example, dr.dk.
In addition, if JavaScript is enabled, the site somehow reloads the current URL without triggering an update to the domain settings. So, if the current site has no domain settings and dr.dk has JavaScript enabled, the current site will reload with JavaScript enabled.
Updated by Soren Stoutner over 7 years ago
- Subject changed from Some sites won't load if the default WebView user agent is used. to Sites won't load if a domain user agent is set that is different than the default user agent.
This bug actually appears to be caused if the user agent in the domain settings is different than the default user agent. Likely what is happening is that the user agent is being set by domain settings, causing a refresh and reloading the current domain.
Updated by Soren Stoutner over 7 years ago
- Subject changed from Sites won't load if a domain user agent is set that is different than the default user agent. to Sites won't load if a domain user agent is set that is different than the current user agent.
Updated by Soren Stoutner over 7 years ago
- Subject changed from Sites won't load if a domain user agent is set that is different than the current user agent. to Sites won’t load if a domain user agent is set that is different than the current user agent.
Updated by Soren Stoutner over 7 years ago
For this bug to be triggered, the target website must switch user agents and perform a URL redirect.
Updated by Soren Stoutner over 7 years ago
The fix for this bug causes a new user agent to not be applied if a website is currently loading. Domain settings are set before the load begins, so if a website has a domain specified user agent, it will be applied before the load begins. But if the website then redirects to a URL that has specified a different user agent, this second user agent will not be applied. Also, if the user presses back while a website is loading, the user agent of the loading website will still be applied irrespective of the specified user agent of the website that is being returned to.
The fixes for these problems would be complex because of deficiencies in the controls provided by Android’s `WebView`. After the website finishes the correct user agent could be applied, but tracking that would be complex. Alternately, we could apply the user agent on every page finish (there might be some bugs to doing this, I haven’t looked at it closely enough). In either case, in the above scenarios, the web server would see a connection from one user agent and then a second connection from the other user agent, which isn’t a real good solution.
A permanent solution after the fork of Privacy WebView would be to modify `WebView’s` behavior to make it more intelligent about switching user agents when loading websites, but those types of changes would be deep and require a lot of maintenance. I’m not sure it would be worth the effort.
Updated by Soren Stoutner over 7 years ago
- Status changed from New to Closed
Updated by Soren Stoutner over 6 years ago
- Priority changed from 3 to Next Release
Updated by Soren Stoutner almost 6 years ago
- Status changed from Closed to In Progress
It might be possible to mitigate this problem by waiting 100 ms after changing the user agent before loading the URL.
Updated by Soren Stoutner almost 6 years ago
- Status changed from In Progress to Closed
The solution ends up being a whole lot more complex than simply delaying the loading of the URL, but I think that now in all circumstances, when a refresh is forced by the changing of the user agent, the target URL will then be explicitly loaded afterwared.
Fixed in commit https://git.stoutner.com/?p=PrivacyBrowser.git;a=commitdiff;h=eb5895f27130aee9da36f06da293ae4a788c75c0