483950 - Remove/hide status bar domain display text

Status: VERIFIED FIXED

(Firefox :: Security, enhancement, P2)

Description

[Gervase Markham [:gerv]]

In bug 480357, we set browser.identity.ssl_domain_display to 1 by default, so that it shows the Public Suffix of HTTPS sites being visited.

If we are going to retain that change, then we should simplify the Firefox UI by hiding the domain display in the status bar which I added a couple of release cycles ago. The two bits of UI are near-duplicates of each other (except that the status bar gives the full domain, not the Public Suffix), and we only need one. 

It's quite late in the cycle to rip the code out, and that would be an unnecessary risk, as we can just use a simple CSS rule in the default skin to hide it. (We would need to decide whether to hide the lock also, or whether to keep that.)

Gerv

Comment 1

[Eddy Nigg (StartCom)]

I think the pad lock hasn't much use these days with browser.identity.ssl_domain_display set to 1. And Larry gives more indications.

+1

Comment 2

[Johnathan Nightingale [:johnath]]

Assuming we retain that change, I agree, the extra copy in the status bar is unnecessary.

Personally, I would leave the padlock in for a release, as a transitional UI.  The site identity button in 3.0 was something many people were likely to miss because of the setting of ssl_domain_display at the time. If the current setting persists we can begin transitioning in earnest, but I think we get most of the advantage here by removing the redundant domain names, and can afford the "echo" of the old indicator for one more release.

If this bug is used to track css-hiding it on branch, then we should have another on file to remove it on trunk, since that can happen any time.

Comment 3

[Alex Faaborg [:faaborg] (Firefox UX)]

>Personally, I would leave the padlock in for a release, as a transitional UI. 

I think Firefox 3 was enough of a transition (but I'm also not that conservative when it comes to gradual transition).

Comment 4

[Mike Connor [:mconnor]]

I think we can just rip it out now, I agree with Alex on this.

Comment 5

[Johnathan Nightingale [:johnath]]

Attachment: Hide label with CSS

Comment 6

[Mike Connor [:mconnor]]

Comment on attachment 370522 [details] [diff] [review]
Hide label with CSS

r=mconnor

Comment 7

[Mike Connor [:mconnor]]

Would be good to land this soon...

Comment 8

[Johnathan Nightingale [:johnath]]

Pushed to mozilla-central - http://hg.mozilla.org/mozilla-central/rev/198b580eb6a2

Comment 9

[Johnathan Nightingale [:johnath]]

Comment on attachment 370522 [details] [diff] [review]
Hide label with CSS

Don't think this blocks, but removing redundant UI is virtuous, and it's a CSS only change.  Would be nice to have beta exposure.

Comment 10

[Steffen Wilberg]

Comments 1, 3 and 4 were in favor of removing the padlock as well, but the patch merely removed the label...

Comment 11

[Mike Beltzner [:beltzner, not reading bugmail]]

Comment on attachment 370522 [details] [diff] [review]
Hide label with CSS

Unclear if this is a complete fix. No half measures.

Comment 12

[Daniel Veditz [:dveditz]]

Comment on attachment 370522 [details] [diff] [review]
Hide label with CSS

"Comment 4" was from the guy who later r+'d the patch as-is, and happens to be the Firefox lead so if he's OK with it it would seem to be a legit improvement.

Currently without the lock we would have no UI to indicate "mixed" ssl mode (the slashed lock icon).

Comment 13

[Mike Connor [:mconnor]]

Comment on attachment 370522 [details] [diff] [review]
Hide label with CSS

fair, but let's not leave it like this, I'd like to indicate broken SSL a bit more obviously in .next.

Comment 14

[Johnathan Nightingale [:johnath]]

http://hg.mozilla.org/releases/mozilla-1.9.1/rev/2776bab52989

Marking this fixed and fixed1.9.1 rather than leaving it open to track the actual removal, and breaking blocker queries.  I'll clone this bug to cover actual removal of the code on trunk.

Comment 15

[u279076]

Would it be at all possible to get a screenshot or clearer explanation of what it is I need to look for when verifying this bug.  I am not sure what it is I am supposed to see (or not see).

Comment 16

[Johnathan Nightingale [:johnath]]

(In reply to comment #15)
> Would it be at all possible to get a screenshot or clearer explanation of what
> it is I need to look for when verifying this bug.  I am not sure what it is I
> am supposed to see (or not see).

1) Load a valid https page like bugzilla
2) Look at the bottom right of the status bar.  In 3.0 (or 3.5 before this patch), you will see a locked padlock and the hostname. Now, with this patch, you should see only the padlock (no hostname).  It's not necessary to repeat the hostname, given that it's now shown in the location bar.

Comment 17

[Alex Faaborg [:faaborg] (Firefox UX)]

Attachment: Screenshot

Screenshot: the domain name label is hidden, but lock icon still appears.

Why did we want to keep the lock icon again, so that we could have the lock with a slash through it?

I always thought that was one of our more ambiguous symbols, it seems to communicate "goodbad!" and the subtly of the implementation issues is quickly lost on the user.

Should we file a follow up bug to remove the lock as well?

Comment 18

[Eddy Nigg (StartCom)]

It could be an idea to move the lock icon to the right side of the address bar - or - create another indicator for mixed content somewhere else.

Comment 19

[Gervase Markham [:gerv]]

We could certainly reconsider how we show that; one option would be a yellow infobar. Another option would be to just silently (well, with Error Console messages) drop all non-SSL content. I believe IE has been making some changes in this area recently.

Gerv

Comment 20

[Johnathan Nightingale [:johnath]]

(In reply to comment #19)
> We could certainly reconsider how we show that; one option would be a yellow
> infobar. Another option would be to just silently (well, with Error Console
> messages) drop all non-SSL content. I believe IE has been making some changes
> in this area recently.

That's been on the wishlist for some time - but requires movement on bug 62178 which is, as they say, a dilly of a pickle.

Comment 21

[Aakash Desai [:aakashd]]

verified FIXED on builds:

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20090526 Minefield/3.6a1pre ID:20090526031623

and

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1pre) Gecko/20090526 Shiretoko/3.5pre ID:20090526031155

Comment 22

[u279076]

I've added https://litmus.mozilla.org/show_test.cgi?id=7741 to Litmus.  It has been placed in the FFx 3.5 BFTs and FFTs.  I'm not sure if we want to put this into the Smoketests or the automated tests.  Marking in-testsuite?