1221711 - about:accounts should not show an insecure lock icon

Status: RESOLVED FIXED

(Firefox for Android Graveyard :: Firefox Accounts, defect)

Description

[Allison Naaktgeboren :ally]

I set up sync on my tablet, and the action=signup flow produces the insecure icon in the urlbar, but without a doorhanger to explain what is going on.

Chenixa mentioned in irc that there is no bug to whitelist about:accounts  for mixed content blocking, so this is it. :)

Comment 1

[Chenxia Liu [:liuche]]

Sorry for not being clearer - the bug is actually that the insecure lock icon should not be shown on about:accounts, not that the doorhanger is not available (that's covered in bug 1099088).

Comment 2

[Nick Alexander :nalexander [he/him]]

How does one ensure about:accounts isn't actually doing insecure things?  The XHTML is trivial, modulo an embedded iframe, which is a mozbrowser (i.e., super-special).  Is it possible that the iframe contents (accounts.firefox.com) are triggering the insecure icon?

markh: How does Desktop arrange for about:accounts to not trigger the insecure icon?

Comment 3

[Mark Hammond [:markh] [:mhammond]]

(In reply to Nick Alexander :nalexander from comment #2)
> markh: How does Desktop arrange for about:accounts to not trigger the
> insecure icon?

It doesn't! Apparently Firefox itself changes the icon in the URL bar for all "chrome" pages, but if you click that icon it shows the lock with the red-line through it and warns "Your login could be compromised". I just opened bug 1221771.

Comment 4

[:Margaret Leibovic]

(In reply to Mark Hammond [:markh] from comment #3)
> (In reply to Nick Alexander :nalexander from comment #2)
> > markh: How does Desktop arrange for about:accounts to not trigger the
> > insecure icon?
> 
> It doesn't! Apparently Firefox itself changes the icon in the URL bar for
> all "chrome" pages, but if you click that icon it shows the lock with the
> red-line through it and warns "Your login could be compromised". I just
> opened bug 1221771.

I just commented in there... I would guess this is probably a bug with the login manager code that decides whether or not a page is secure.

Comment 5

[Nick Alexander :nalexander [he/him]]

This is very likely addressed by Bug 1099088, but I'm waiting on ahunt to confirm.  ahunt, would you mind testing and closing this ticket if we are good?

Comment 6

[Andrzej Hunt :ahunt]

(In reply to Nick Alexander :nalexander from comment #5)
> This is very likely addressed by Bug 1099088, but I'm waiting on ahunt to
> confirm.  ahunt, would you mind testing and closing this ticket if we are
> good?

This actually seems to have been fixed by Bug 1221771 (affecting both desktop and mobile) - we were being passed an incorrect insecure state from lower in the code, which is fixed now.

Bug 1099088 only affected the main site status (i.e. insecure, secure, or internal), and didn't care about insecure logins - we still showed the insecure lock icon, in addition to showing the insecure login information in the doorhanger after 1099088 landed and before 1221771 landed.