Remove/hide status bar domain display text

VERIFIED FIXED in Firefox 3.5b4

Status

()

P2
enhancement
VERIFIED FIXED
10 years ago
10 years ago

People

(Reporter: gerv, Assigned: johnath)

Tracking

({verified1.9.1})

3.5 Branch
Firefox 3.5b4
verified1.9.1
Points:
---
Bug Flags:
wanted-firefox3.5 +
in-testsuite ?
in-litmus +

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(2 attachments)

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

10 years ago
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
(Assignee)

Comment 2

10 years ago
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.
>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).
I think we can just rip it out now, I agree with Alex on this.
(Assignee)

Comment 5

10 years ago
Created attachment 370522 [details] [diff] [review]
Hide label with CSS
Attachment #370522 - Flags: review?(mconnor)
Assignee: nobody → johnath

Updated

10 years ago
Attachment #370522 - Flags: review?(mconnor)
Comment on attachment 370522 [details] [diff] [review]
Hide label with CSS

r=mconnor
Attachment #370522 - Flags: review+
Would be good to land this soon...
Status: NEW → ASSIGNED
Flags: wanted-firefox3.5+
Priority: -- → P2
Target Milestone: --- → Firefox 3.5b4
(Assignee)

Comment 8

10 years ago
Pushed to mozilla-central - http://hg.mozilla.org/mozilla-central/rev/198b580eb6a2
Whiteboard: [baking on trunk]
(Assignee)

Comment 9

10 years ago
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.
Attachment #370522 - Flags: approval1.9.1?

Comment 10

10 years ago
Comments 1, 3 and 4 were in favor of removing the padlock as well, but the patch merely removed the label...
Comment on attachment 370522 [details] [diff] [review]
Hide label with CSS

Unclear if this is a complete fix. No half measures.
Attachment #370522 - Flags: approval1.9.1? → approval1.9.1-
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).
Attachment #370522 - Flags: approval1.9.1- → approval1.9.1?

Updated

10 years ago
Attachment #370522 - Flags: approval1.9.1? → approval1.9.1+
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.
(Assignee)

Comment 14

10 years ago
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.
Status: ASSIGNED → RESOLVED
Last Resolved: 10 years ago
Keywords: fixed1.9.1
Resolution: --- → FIXED
Whiteboard: [baking on trunk]
(Assignee)

Updated

10 years ago
Blocks: 493010
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).
(Assignee)

Comment 16

10 years ago
(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.
Created attachment 379301 [details]
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

10 years ago
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.
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
(Assignee)

Comment 20

10 years ago
(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.
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
Status: RESOLVED → VERIFIED
Keywords: fixed1.9.1 → verified1.9.1
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?
Flags: in-testsuite?
Flags: in-litmus+
You need to log in before you can comment on or make changes to this bug.