Bug #1067


App bar URL doesn't refresh on broken internet connection

Added by v ... 11 months ago. Updated 11 months ago.

In Progress
Start date:
Due date:
% Done:


Estimated time:


  1. Go to a web page ;
  2. Turn off your internet connection ;
  3. Click on a link in the web page previously loaded ;
  4. Because there is no internet connection, the WebView is showing us that the link we clicked on is not available (normal) ;
  5. However, the URL bar continues to display the previous URL (the bug) ;
  6. Turn on your internet connection ;
  7. Tap to the refresh button ;
  8. The URL used to refresh the page is the last one, which previously has not been resolved, and not the displayed one. So, it only seems to be a bug relative to the view.

I suppose the refresh of the URL bar is done after the URL is resolved. Therefore, to fix that, the refresh has to be done before the possibly resolution of the domain name.

See the attached screenshot.


incorrect-app-bar-url.jpg (102 KB) incorrect-app-bar-url.jpg v ..., 08/16/2023 03:32 PM
Actions #1

Updated by v ... 11 months ago

  • Description updated (diff)
Actions #2

Updated by v ... 11 months ago

  • Description updated (diff)
Actions #3

Updated by Soren Stoutner 11 months ago

  • Status changed from New to Closed

This behavior exists to fix a much more bothersome behavior, which is that by default there used to be along delay between when a user clicked on a link and when it populated the URL text edit. It is much more important to me that Privacy Browser works well for users who have an internet connection than for those who do not have an internet connection. As such, I think the current behavior is the desired behavior.

Regarding a person who might want to load a URL that didn't go through because their internet connection was interrupted, instead of using refresh, they can simply tap on the unloaded URL in the URL bar (which displays the keyboard) and they tap the enter key.

Actions #4

Updated by v ... 11 months ago

I wrote in the steps for reproducing the problem "Tap on the refresh button", but it is not something specific with the refresh button. If you look at the screenshot, you'll see that the URL in the URL bar is not the same as the URL reported by WebView as being unreachable. The URL reported by WebView is the URL I wanted to reach, whereas the URL in the URL bar is the n-1 in the history. So your suggestion, of tapping on the URL bar and then tapping the Enter key, won't work.

Actions #5

Updated by Soren Stoutner 11 months ago

  • Status changed from Closed to In Progress

You are correct. My previous comments were written based on my experiences with spotty internet connections (or spotty VPNs, like Tor). If DNS lookup fails (as is the case if airplane mode is enabled), then the new URL never gets placed in the URL text edit. Currently I snag the URL from onPageStarted, but that never gets called if DNS resolution fails.,%20java.lang.String,

However, it would be possible to pull this information from onReceivedError.,%20android.webkit.WebResourceRequest,%20android.webkit.WebResourceError)

Actions #6

Updated by v ... 11 months ago

From onReceivedError's documentation :

Report web resource loading error to the host application. These errors usually indicate inability to connect to the server. Note that unlike the deprecated version of the callback, the new version will be called for any resource (iframe, image, etc.), not just for the main page. Thus, it is recommended to perform minimum required work in this callback.

Do you think the underlined part might be a problem?

Actions #7

Updated by Soren Stoutner 11 months ago

Initially I thought so, but the method includes a WebResourceRequest, which has a isForMainFrame method. So, it should be fairly easy to determine if the error is for the main URL.

Actions #8

Updated by v ... 11 months ago

Good catch.


Also available in: Atom PDF