451833 - Highlight the domain name in the address bar

Status: VERIFIED FIXED

(Firefox :: Address Bar, enhancement)

Description

[-]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1

There are a few extensions, which offers this functionality, but maybe it should be a default feature (has to be discussed), that every domain-name in the URL bar will be highlighted to focus attention to it and makes it easier to see, whether it's the right page.

Reproducible: Always

Steps to Reproduce:
1.
2.
3.

Comment 1

[Mardeg]

This was tried in alpha versions of Firefox 3 and failed see https://bugzilla.mozilla.org/show_bug.cgi?id=388135#c5 - The alternatives implemented were bug 383183 and bug 329292 (an intro ? icon for the Larry dialog is bug 426835)
This is likely a dupe of bug 366797

Comment 2

[Jesse Ruderman]

Since bug 366797 covered many things and that part of bug 366797 was reverted, it doesn't make sense to mark this as a dup.

Comment 3

[Dão Gottwald [:dao]]

Attachment: patch

this is a new implementation and highlights the full domain

Comment 4

[Dão Gottwald [:dao]]

Comment on attachment 336757 [details] [diff] [review]
patch

Can't hurt to get a code review, although it still needs to be figured out if this bug is wanted.

Comment 5

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Comment on attachment 336757 [details] [diff] [review]
patch

Gah, we have *got* to make this selection stuff dynamically extensible

Comment 6

[Dão Gottwald [:dao]]

Comment on attachment 336757 [details] [diff] [review]
patch

>+            this.controller.repaintSelection(this.selectionType);

This line is unneeded overhead, consider it removed.

Comment 7

[Dão Gottwald [:dao]]

Attachment: patch

removed repaintSelection

Comment 8

[Mardeg]

Just to clarify, is this for all domains or just the non-SSL domains? There is already an about:config pref for SSL, see http://kb.mozillazine.org/Browser.identity.ssl_domain_display

Comment 9

[Dão Gottwald [:dao]]

(In reply to comment #8)
> Just to clarify, is this for all domains or just the non-SSL domains?

For all.

Comment 11

[Someone]

I am willing for this feature to be added due to other browsers such as chrome and IE8 offering.

Some people might like it and some wont so it should be an option in any case.

Comment 13

[wiki131wiki]

I agree, I think that this would be a useful feature but to make it as an option.

Comment 14

[Mark]

Voted for this. Would be nice to have but with a on/off switch in about:config.

Just wondering but somewhere in the firefox 3.0 dev cycly the Locationbar2 mod was build into firefox. Did that part got deleted at some point in the 3.0 dev cycle since it's not in there and not in 3.5

If it was deleted could someone explain why?

Thanx,
Mark

Comment 16

[Ilhan Yumer]

(In reply to comment #11)
> I am willing for this feature to be added due to other browsers such as chrome
> and IE8 offering.
> 
> Some people might like it and some wont so it should be an option in any case.

Google Chrome highlights with sub-domains. On the other hand IE8 highlights only the domain-name. Highlighting only the domain-name will be better.

Comment 17

[Frank Yan (:fryn)]

(In reply to comment #16)
> Google Chrome highlights with sub-domains. On the other hand IE8 highlights
> only the domain-name. Highlighting only the domain-name will be better.

Agreed. The current Firefox 4 mockup by Stephen Horlander also highlights the domain name more prominently than the sub-domain(s).
https://wiki.mozilla.org/Firefox/4.0_Windows_Theme_Mockups

Jono also wrote about some users not understanding urls:
http://jonoscript.wordpress.com/2010/02/18/some-people-cant-read-urls/

URL hierarchy is confusing since the most important part is sandwiched in the middle (sub.domains.IMPORTANT.TLD/path/...)
Implementing Horlander's mockup might mitigate this.

Comment 18

[imradyurrad]

Should this be a papercut bug?
https://bugzilla.mozilla.org/show_bug.cgi?id=565510

Comment 19

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

Does this patch highlight the full domain name or does it match the mockups from comment 17?

Comment 20

[Dão Gottwald [:dao]]

(In reply to comment #19)
> does it match the mockups from comment 17?

The patch is two years old. Besides, I don't see mockups related to this on the page linked to in comment 17, probably because that comment is four months old.

Comment 21

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

Ooops, I didn't notice the datestamps :) Well, do we still want this as part of the Firefox 4 theme revamp?

Comment 22

[Dão Gottwald [:dao]]

Attachment: patch

this is the two year old patch updated to tip, untested

Comment 23

[Dão Gottwald [:dao]]

(In reply to comment #21)
> Ooops, I didn't notice the datestamps :) Well, do we still want this as part of
> the Firefox 4 theme revamp?

This particular bug doesn't have much to do with the theme, it just highlights the domain like IE and Chrome do it.

Comment 24

[Michael Monreal [:micmon]]

(In reply to comment #20)
> Besides, I don't see mockups related to this on the page linked to 
> in comment 17, probably because that comment is four months old.

Previous mockups had something like this¹ which I think is what we still want.

[1] http://blog.stephenhorlander.com/2009/12/21/windows-themeui-update/

Comment 25

[Dão Gottwald [:dao]]

(In reply to comment #24)
> (In reply to comment #20)
> > Besides, I don't see mockups related to this on the page linked to 
> > in comment 17, probably because that comment is four months old.
> 
> Previous mockups had something like this¹ which I think is what we still want.
> 
> [1] http://blog.stephenhorlander.com/2009/12/21/windows-themeui-update/

This has unclear interaction implications as it's using boldface. For this reason the selection controller (used by the current patch) only allows changing the foreground and background color, AFAIK. Chrome and IE probably have similar implementations because of this.

Comment 26

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

Let's wait for Shorlander to tell us what it should look like.

Comment 27

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

I've been working with shorlander on this so I can fill in the missing information while he's off on vacation. Here is a quick mockup of the identity block in the normal (non-sll or ev) state:

http://people.mozilla.com/~faaborg/files/20100625-tabsOnTop/tabsOnTop.png

This still needs to sent out for more public comment, but the overall idea is that the identity block and the URL should not contain redundant information.  When you select in the path, the entire area converts to text (maintaining position, the subdomain and domain will probably already be part of the string, just white text on white background and lower in the z-order).

Comment 28

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

Faaborg: thanks - feels like there should be a new bug for that, as that's a much different highlight. Is there a UI spec page for this? We don't have a lot more time for public comment before feature freeze on Sept 1

Comment 29

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

>Is there a UI spec page for this?

it's only half complete, I got pulled off of it last week when Sync and Account Manager needed updated mockups.  I'm hoping to have complete mockups and a blog post up mid next week.

Comment 30

[Daniel C]

Is it possible to get the current patch here reviewed and into a beta?

This change is very conservative compared to the mockups, other browsers and also the changes that were initially committed in the Fx 3 cycle.

As far as I can tell, this sets the protocol:// (and any optional login credentials) to grey and anything from the first slash (inclusive) after the domain onwards to grey, leaving the domain black. There is no eTLD or subdomain analysis.

Any more cosmetic changes could come afterwards, and any radical changes like the "identity block" Alex hinted at could be looked at for Firefox 4.1.

If it was up to me here's what I would arrange to be done:

1. Post a screenshot of what the patch does.
2. ui-review it
3. Form a new, more conservative, doable-for-Fx-4 mockup and policy
4. Get the patch reviewed (at a guess, Gavin and roc and maybe a security check from jonath)
5. Write a test for various URL possibilities and expected outcomes
6. Check it in
7. (All the other things that have to be done for Fx4)
8. Release
9. Beers all round

One thing I have noticed from looking through the patch is that a port number will be highlighted as part of the domain (http://www.delorie.com:81/some/url.txt for example would be www.delorie.com:81). This doesn't happen in my test of Chromium on Linux (5.0.375.127). My guess is that it shouldn't be highlighted.

Comment 31

[Daniel C]

OK, it seems like bug 587901 is for the Identity Block to display the domain name (fixed for Fx 4) and bug 588270 is for having the Identity Block as part of the displayed URL (post Fx 4).

Is that correct? Is it correct to say that if bug 588270 is fixed, this bug will be WONTFIX (in it's current form of displaying URLs similar to how IE and Chrome do)?

Comment 32

[Ilhan Yumer]

I think there is problem with the sites; www.nic.tr and www.tsk.tr
I think that they should be highlighted as nic.tr and tsk.tr
However Firefox highlights them as www.nic.tr and www.tsk.tr

Comment 34

[Jo Hermans]

(In reply to comment #32)
> I think there is problem with the sites; www.nic.tr and www.tsk.tr
> I think that they should be highlighted as nic.tr and tsk.tr
> However Firefox highlights them as www.nic.tr and www.tsk.tr

see bug 571433

Comment 35

[Dão Gottwald [:dao]]

Attachment: patch

updated to tip

Comment 36

[Daniel C]

Dão, do you think that the last part of comment 30 should be fixed?

> One thing I have noticed from looking through the patch is that a port number
> will be highlighted as part of the domain
> (http://www.delorie.com:81/some/url.txt for example would be
> www.delorie.com:81). This doesn't happen in my test of Chromium on Linux
> (5.0.375.127). My guess is that it shouldn't be highlighted.

If so, then I think altering the regex as follows would be enough.

- ^((?:http|https|ftp):\/\/(?:[^\/]+@)?)([^\/]+)
+ ^((?:http|https|ftp):\/\/(?:[^\/]+@)?)([^:\/]+)

Comment 37

[Dão Gottwald [:dao]]

I don't really see why the port should be excluded, but as you say it's a trivial modification, so if somebody could tell me why it's the right thing to do I can make that change.

Comment 38

[Dão Gottwald [:dao]]

Attachment: patch

This is on top of the patch in bug 597769.

Comment 39

[Please Ignore This Troll (Account Disabled)]

Dao, in most cases users don't care about port, since in 99% it's http or https (and in case it's https and you type http - in 99% that won't cause a problem for you). Ftp sites usually can be easily distinguished by their outlook.
And the port itself is not so important, for a user when he needs to pronounce the address of the page.

Comment 40

[Daniel Veditz [:dveditz]]

(In reply to comment #39)
> Dao, in most cases users don't care about port, since in 99% it's http or https

And in that 99.9+% there is no port at all to highlight. Even if the link or user specified :80 or :443 when navigating our URL canonicalization will remove the standard ports when we display it.

> And the port itself is not so important, for a user when he needs to pronounce
> the address of the page.

When there is a port it is critical that a user "pronounce" it, otherwise they will end up on the wrong site. It's extremely unusual to have an explicit port and we should highlight that fact.

Comment 41

[Alex Limi (:limi) — Firefox UX Team]

(In reply to comment #40)
> When there is a port it is critical that a user "pronounce" it, otherwise they
> will end up on the wrong site. It's extremely unusual to have an explicit port
> and we should highlight that fact.

Yeah, agreed. It might be a bit less visually pleasing, but it's definitely part of what domain you are on, and example.com:8080 is not the same as example.com.

Comment 42

[Daniel Jackson]

(In reply to comment #41)

The main point of this is that a user is not misled about the domain they are on.

The subdomain will rightly be greyed out so, e.g. paypal.com.evil.net, doesn't fool the user. 

Hilighting the port would be useless/misleading -- this is supposed to be indicating the domain name only, not the specific host/port (which would be specific to the sub-domain anyway)

Comment 43

[marginal]

I'm not into the technical aspects of implementing this, but can't help but notice that no-one has pointed out that the previous two mockups linked above are both awful: neither shows the protocol ('http://') section of the uri.

How has it been decided that the protocol is of no importance?

Furthermore, the second example (tabsontop) is awful also because it wastes horizontal space. There is zero spare horizontal space in the uri field. There is none to waste. For proof, see my previous two sentences. You need to fit the protocol into the uri field.

Thirdly, the tabsontop mockup link is awful because it is ugly, and what is the function supposed to be of a dropdown list for the domain name? Have there been numerous feature requests from users who want to visit exactly the same uri but with the domain name different? I think not.

All that is needed is a background colour against the domain name section of the uri, inline (not quite the way my current 3.5 browser shows the domain name PLUS the full uri on https sites, wasting precious horizontal space in the uri field).

Nothing else needed, just some kind of background colour highlighting, and only on the domain name section. No?

Comment 44

[imradyurrad]

What's the target milestone for this?

Comment 45

[Shawn Wilsher :sdwilsh]

(In reply to comment #44)
> What's the target milestone for this?
When it's done.  It's not making Firefox 4 if that is what you are asking.

Comment 46

[Jerry]

(In reply to comment #43)
> I'm not into the technical aspects of implementing this, but can't help but
> notice that no-one has pointed out that the previous two mockups linked above
> are both awful: neither shows the protocol ('http://') section of the uri.
> 
> How has it been decided that the protocol is of no importance?
> 
> Furthermore, the second example (tabsontop) is awful also because it wastes
> horizontal space. There is zero spare horizontal space in the uri field. There
> is none to waste. For proof, see my previous two sentences. You need to fit the
> protocol into the uri field.
> 
> Thirdly, the tabsontop mockup link is awful because it is ugly, and what is the
> function supposed to be of a dropdown list for the domain name? Have there been
> numerous feature requests from users who want to visit exactly the same uri but
> with the domain name different? I think not.
> 
> All that is needed is a background colour against the domain name section of
> the uri, inline (not quite the way my current 3.5 browser shows the domain name
> PLUS the full uri on https sites, wasting precious horizontal space in the uri
> field).
> 
> Nothing else needed, just some kind of background colour highlighting, and only
> on the domain name section. No?

I concur -you presented your case very well (keep it simple).

This is a very important security enhancement that is well over due. Security bugs, and/or enhancements should always take priority over anything else. IE has had this security feature for quite some time. Firefox should not continue to postpone this security enhancement, because it may give users the erroneous perception that security enhancements are not at the top of developers priority list, which I know nothing can be further from the truth.

Comment 47

[Dão Gottwald [:dao]]

Opera: http://my.opera.com/desktopteam/blog/2010/11/17/new-and-improved

Comment 48

[David Vo [:auscompgeek]]

(In reply to comment #43)
> I'm not into the technical aspects of implementing this, but can't help but
> notice that no-one has pointed out that the previous two mockups linked above
> are both awful: neither shows the protocol ('http://') section of the uri.
> How has it been decided that the protocol is of no importance?

Most sites use the http protocol, https/ftp would assumably be still displayed in some form.

Comment 49

[Marco B.]

Will this bug land in Fx4? I see [target-betaN], but no hard- or softblocker-tag?

Comment 50

[Alex Limi (:limi) — Firefox UX Team]

(In reply to comment #49)
> Will this bug land in Fx4? I see [target-betaN], but no hard- or
> softblocker-tag?

No, it didn't get blocking status, and won't make 4.0. the [target-betaN] is unrelated to the blocker status, sorry about the confusion there.

Comment 51

[Dão Gottwald [:dao]]

Attachment: updated to tip

builds will be available at http://ftp.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/[e-mail]-4c4ad78fd4a6

Comment 52

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

Comment on attachment 522352 [details] [diff] [review]
updated to tip

granting just based on described functionality

Comment 53

[Marco B.]

What is the status of this feature? I thought this should land together with the new identity block?

Comment 54

[Oz]

This feature it's a must, it is nice to have add-ons (locationbar2) but there are some browser features that must be added by default and this is one of them.

Comment 55

[Dão Gottwald [:dao]]

Attachment: hidden pref and test added (r=roc, ui-r=faaborg)

Comment 56

[Shawn Wilsher :sdwilsh]

Comment on attachment 529440 [details] [diff] [review]
hidden pref and test added (r=roc, ui-r=faaborg)

Review of attachment 529440 [details] [diff] [review]:

I'd like to see one additional test that checks that the hidden preference does in fact turn this feature off.  r=sdwilsh with comments addressed.

::: browser/base/content/test/browser_urlHighlight.js
@@ +1,1 @@
+function testVal(aExpected, aExplicitValue) {

You don't ever call this with aExplicitValue, so you can remove it.

@@ +44,5 @@
+  testVal("mailto:[e-mail]");
+  testVal("gopher://mozilla.org/");
+  testVal("about:config");
+
+  Services.prefs.clearUserPref("browser.urlbar.formatting.enabled");

You should do this in a function added with registerCleanupFunction in case something happens to throw (unlikely with the current test, but tests change, and I'd rather future-proof it).

::: browser/base/content/urlbarBindings.xml
@@ +202,5 @@
+            baseDomain = Services.eTLD.getBaseDomainFromHost(domain);
+          } catch (e) {}
+          let segments = function (s) s.replace(/[^.]*/g, "").length + 1;
+          let subSegments = segments(domain) - segments(baseDomain);
+          let subDomain = domain.match(new RegExp("(?:[^.]*\.){" + subSegments + "}"))[0];

I'm so very glad you wrote a test for this :)

Comment 57

[Stefan]

Thanks for rendering the url in the address bar unreadable (except for the domain part, of course).

Comment 58

[Stefan]

Attachment: screenshot (unredable url in address bar)

Comment 59

[Dão Gottwald [:dao]]

http://hg.mozilla.org/mozilla-central/rev/63c46c761a92

Comment 60

[Stefan]

Shall I file a new bug for my issue in comment #58?

Comment 61

[Can]

The change looks very good on me:

http://i.imgur.com/xRByz.jpg

thanks for check-in.

Comment 62

[Dão Gottwald [:dao]]

(In reply to comment #60)
> Shall I file a new bug for my issue in comment #58?

yep

Comment 63

[Gary [:streetwolf52]]

On my system the highlighting is not dark enough.  I can hardly tell the difference between the highlighted text and the rest of the URL.  Is there a pref to make it darker?

Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0a1) Gecko/20110502 Firefox/6.0a1 - Build ID: 20110503014006

Comment 64

[Alfred Kayser]

This is not done in a very 'themable' way. The 'GetURLSecondaryColor' just gets the color value of 'graytext', why is that? Why not using a span with class?

Comment 65

[Dão Gottwald [:dao]]

(In reply to comment #63)
> On my system the highlighting is not dark enough.  I can hardly tell the
> difference between the highlighted text and the rest of the URL.  Is there a
> pref to make it darker?

only browser.urlbar.formatting.enabled

(In reply to comment #64)
> This is not done in a very 'themable' way. The 'GetURLSecondaryColor' just gets
> the color value of 'graytext', why is that?

Ideally bug 256773 would solve this.

> Why not using a span with class?

This would require a more invasive implementation and didn't perform very well last time we tried it.

Comment 66

[Jerry]

Good enough for me, how do I enable this feature in Firefox 4.0.1?

Comment 67

[Dão Gottwald [:dao]]

> how do I enable this feature in Firefox 4.0.1?

Firefox 4.0.1 doesn't have this feature, but you can install an add-on such as <https://addons.mozilla.org/firefox/addon/locationbar%C2%B2/>.

Comment 68

[Oz]

The builds link is dead, any new link? 


Thanks

Comment 69

[Carlos Alén Silva]

(In reply to comment #66)
> Good enough for me, how do I enable this feature in Firefox 4.0.1?

You can also try Smart Text, which offers additional features besides domain highlighting.

https://addons.mozilla.org/en-US/firefox/addon/smart-text/

Comment 70

[Jerry]

Thanks!

On a related note, every time I am going to add a new add-on Firefox displays a "Software Installation" dialog box with the following caption:

"Install add-ons only from authors you trust. Malicious software can damage your computer or violate your privacy."

How does one established a trusted author? How does some established a trusted add-on?

Comment 71

[Jerry]

Firefox 4.0.1 new redesign of the Site Identity Button with its inconspicuous multi-colored status background is in my opinion a very bad idea. Did we not learn anything from the old multi-colored Homeland Security Advisory System?
 
The reason the multi-colored Homeland Security Advisory System was recently changed, is because no one could remember what it meant.

What happened to KISS (Keep It Simple Stupid), Don’t Make Me Think (great Best Seller read on Web Design/Usability), we need to bring the Padlock icon (Example: Green Padlock icon = Secure, and Grayed-Out Padlock icon = Unsecure) back as soon as possible, and place it where it belongs before Site Identity Button. 

Everyone that has every used a browser is already familiar with the Padlock icon/symbol, and knows what it means, and everyone who has ever used a computer knows what a green vs grayed-out icon means –no explanation, retraining, remembering, etc... required.

Comment 72

[Marco Bonardo [:mak]]

Jerry, your comment is off-topic, since has nothing to do with this bug.
It's also in the wrong place, since this is a resolved bug.
Please move your thoughts to a more appropriate place, like your own bug report or mozilla.dev.usability newsgroup.

Comment 73

[Jerry]

Sorry, I pasted it on the wrong browser tab...

Comment 74

[Jerry]

Post number 70 is related though.

Comment 75

[Mark]

please STOP posting in here! I already removed myself from the CC but i somehow keep getting mails from this bug. QUIT IT! It's implemented and heavily oftopic the last dozen posts.

Comment 76

[Florian J. [:FeuerFliege]]

Back to topic.

Highlight for UK domains like foo.co.uk, foo.police.uk and even foo.bar.sch.uk works fine, but it does not work for foo.parliament.uk

Comment 77

[Ilhan Yumer]

there is problem with tsk.tr domains i think. there are totally 35 domainnames that end with tsk.tr (source: https://www.nic.tr/index.php?USRACTN=YEARSTAT#tsk.tr ) but it always highlights the tsk.tr part such as in http://www.kkk.tsk.tr/

Where is the related bug?

Comment 78

[Jo Hermans]

(In reply to comment #77)
> there is problem with tsk.tr domains i think. there are totally 35 domainnames
> that end with tsk.tr (source:
> https://www.nic.tr/index.php?USRACTN=YEARSTAT#tsk.tr ) but it always highlights
> the tsk.tr part such as in http://www.kkk.tsk.tr/
> 
> Where is the related bug?

That was supposed to have been fixed in bug 606922. Maybe the ! exception rule doesn't work ok ? That might explain comment 76 too.

Please don't comment here anymore, file new bugs or (better) look if it has been filed before.

Comment 79

[Peter Lairo]

This bug is marked "RESOLVED FIXED" but I am not seeing a highlighted URL in my nightly builds[1]. On which branch has this fix landed? Is it OFF by default?

[1] Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0a1) Gecko/20110430 Firefox/6.0a1 ID:20110430030554

Comment 80

[Can]

(In reply to comment #79)
> This bug is marked "RESOLVED FIXED" but I am not seeing a highlighted URL in my
> nightly builds[1]. On which branch has this fix landed? Is it OFF by default?
> 
> [1] Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0a1) Gecko/20110430 Firefox/6.0a1
> ID:20110430030554

you are not using the latest nightly build. you have to update.

Comment 81

[Peter Lairo]

Attachment: Screenshot of domain highlighting in Windows 7

You're right! I didn't realize my updates were lagging so far behind (I've been using the release build a lot lately because Battlefield Play4Free doesn't work with the nightly builds).

Comment 82

[Simona Badau, Desktop QA]

Verified on: 
Mozilla/5.0 (Windows NT 5.1; rv:6.0a1) Gecko/20110505 Firefox/6.0a1

Comment 83

[Asa Dotzler [:asa]]

Sorry if my status Whiteboard note caused confusion or concern. The note was *not* an indication that the release team has evaluated this feature and determined that it needs to be backed out. The Whiteboard note is just a record of why the release team is tracking this issue in the first place -- that it's a new feature that hasn't yet fully proved itself for this release. I've udpated the Whiteboard to say "[tracking+ because this is new feature in 6]" which should hopefully be less alarming.

Comment 84

[Asa Dotzler [:asa]]

Dao, it looks like all the dependencies here are fully cleared. Do you know of anything else that would get in the way of this feature shipping in 6? 

(Note, my question in this closed bug is to Dao. If anyone other than Dao or one of the module peers or reviewers responds, I'm not going to be happy.)

Comment 85

[Dão Gottwald [:dao]]

(In reply to comment #84)
> Dao, it looks like all the dependencies here are fully cleared.

Yep.

> Do you know of anything else that would get in the way of this feature
> shipping in 6? 

Nope.

Comment 86

[Philip Chee]

Is [sg:want] still needed?

Comment 87

[Jesse Ruderman]

We usually don't remove [sg:want] from bugs just because they're fixed, if that's what you're asking.