Added by Soren Stoutner over 7 years ago. Updated almost 6 years ago.
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.
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.
For this bug to be triggered, the target website must switch user agents and perform a URL redirect.
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.
It might be possible to mitigate this problem by waiting 100 ms after changing the user agent before loading the URL.
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