135178 - Wrong lock icon with "about" pages

Status: VERIFIED DUPLICATE of bug 144056

(Core Graveyard :: Security: UI, defect)

Description

[Kai Engert [:KaiE:]]

This is not a new bug, I can reproduce it even with 0.9.4 based versions of Mozilla.

Open a https page.
Wait until the lock icon goes to the secure closed state.
From the help menu, select "about plug-ins".
Actual behaviour: Lock icon stays "secure" and tooltip continues to show the
wrong text.
Expected behaviour: Mozilla should behave like it usually does when leaving a
secure page.

Alternate way to reproduce: Instead of chosing "about plug-ins", you also can
enter "about:mozilla" in the URL bar and press enter.

The problem is that the security code tries to filter out those requests that
seem relevant. But obviously, we still do not have the complete list of
protocols we must care for.

We are currently using the following code:


  // We are only interested in requests that load in the browser window...
  nsCOMPtr<nsIHttpChannel> httpRequest(do_QueryInterface(channel));
  if (!httpRequest) {
    nsCOMPtr<nsIFileChannel> fileRequest(do_QueryInterface(channel));
    if (!fileRequest) {
      nsCOMPtr<nsIWyciwygChannel> wyciwygRequest(do_QueryInterface(channel));
      if (!wyciwygRequest) {
        nsCOMPtr<nsIFTPChannel> ftpRequest(do_QueryInterface(channel));
        if (!ftpRequest) {
          PR_LOG(gSecureDocLog, PR_LOG_DEBUG,
                 ("SecureUI:%p: OnStateChange: not a relevant request\n", this));
          return NS_OK;
        }
      }
    }
  }

But that's not sufficient, as I mentioned in bug 130949, we need a way to
generally find out, whether a given new request will change the displayed
content in the browser window or not.

Sure, for now we can try to find out how to detect the about protocol.

But until we find a generic way, we always risk that new protocols get added,
which we are not aware of.

Comment 1

[Ben Bucksch (:BenB)]

This has been found and reported independently by HJ. That bug is open, open
beats closed, dupping. I will not open this bug per the security policy, but
mention in the other bug that this bug has code info.

*** This bug has been marked as a duplicate of 144056 ***

Comment 2

[John Unruh]

Verified dupe.