Update unknown site page after "Open" was pressed

[Marcono1234]

Problem

In some cases the unknown site extension page remains visible in Chrome and Firefox after pressing the "Open" button. Situations where this occurs are:

• Direct download URLs, e.g. https://repo1.maven.org/maven2/com/github/spotbugs/spotbugs-annotations/4.7.3/spotbugs-annotations-4.7.3.jar
• Redirects which lead to custom URIs, e.g. https://tinyurl.com/mrywcnhm (redirects to vscode://vscode.git)

Possible solution

After pressing the "Open" button update the page and the tab title (?) to indicate that the site was opened / is being opened, for example by replacing the content with "Opened site \<domain>" (with domain having Unicode characters displayed?).

To account for the cases where Chrome and Firefox do actually display the target site, it might be good to add some delay to updating the blocked page content (a few hundred milliseconds) to prevent it from quickly flashing before the target site opens, and to be (in most cases) only visible if Chrome and Firefox do not display a different site.

[Marcono1234]

Updating page title and clearing the body seems to be possible in extension/pages/blocked-unknown.js after the promise returned by browser.runtime.sendMessage was resolved:

.then(
  (_response) => {
    // If page is still open after some time, assume it was a direct download URL and
    // therefore browser did not change page; clear page content to avoid confusion
    setTimeout(() => {
      console.info(
        `Clearing page for URL ${urlValue} because content appears to not have changed`
      )
      document.title = urlValue
      document.body.innerHTML = ''
    }, 1000)
  },
  (rejected) => {
    console.error(
      `Failed sending message to open blocked URL ${urlValue}`,
      rejected
    )
  }
)

However, clearing the favicon might not be easily possible, and changing the URL without triggering a second page load might not be possible at all. window.history.replaceState throws an exception when trying to set the URL (probably due to protocol mismatch).