Highlight the domain name in the address bar

VERIFIED FIXED in Firefox 6

Status

()

Firefox
Location Bar
--
enhancement
VERIFIED FIXED
9 years ago
2 years ago

People

(Reporter: -, Assigned: dao)

Tracking

({ux-visual-hierarchy})

Trunk
Firefox 6
ux-visual-hierarchy
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(blocking2.0 -)

Details

(Whiteboard: [tracking+ because it's new in 6] [sg:want][parity-IE][parity-chrome][parity-opera])

Attachments

(3 attachments, 6 obsolete attachments)

(Reporter)

Description

9 years ago
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

9 years ago
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

9 years ago
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.
Blocks: 366797
Status: UNCONFIRMED → NEW
Component: Phishing Protection → Location Bar and Autocomplete
Ever confirmed: true
QA Contact: phishing.protection → location.bar
Summary: Domain-name highlighting → Highlight the domain name in the address bar
Whiteboard: [sg:want]
Version: unspecified → Trunk
(Assignee)

Updated

9 years ago
Whiteboard: [sg:want] → [sg:want] [parity-IE] [parity-gbrowser]
(Assignee)

Comment 3

9 years ago
Created attachment 336757 [details] [diff] [review]
patch

this is a new implementation and highlights the full domain
Assignee: nobody → dao
(Assignee)

Updated

9 years ago
Attachment #336757 - Flags: superreview?(roc)
Attachment #336757 - Flags: review?(gavin.sharp)
(Assignee)

Comment 4

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

Updated

9 years ago
Attachment #336757 - Flags: review?(roc)
(Assignee)

Updated

9 years ago
Flags: wanted-firefox3.1?
Comment on attachment 336757 [details] [diff] [review]
patch

Gah, we have *got* to make this selection stuff dynamically extensible
Attachment #336757 - Flags: superreview?(roc)
Attachment #336757 - Flags: superreview+
Attachment #336757 - Flags: review?(roc)
Attachment #336757 - Flags: review+
(Assignee)

Updated

9 years ago
Depends on: 256773
(Assignee)

Updated

9 years ago
Whiteboard: [sg:want] [parity-IE] [parity-gbrowser] → [sg:want] [parity-IE] [parity-chrome]
(Assignee)

Comment 6

9 years ago
Comment on attachment 336757 [details] [diff] [review]
patch

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

This line is unneeded overhead, consider it removed.
(Assignee)

Comment 7

9 years ago
Created attachment 337861 [details] [diff] [review]
patch

removed repaintSelection
Attachment #336757 - Attachment is obsolete: true
Attachment #336757 - Flags: review?(gavin.sharp)
(Assignee)

Updated

9 years ago
Assignee: dao → nobody
Flags: wanted-firefox3.1?

Comment 8

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

Comment 9

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

For all.

Updated

9 years ago
Duplicate of this bug: 468222
Flags: wanted-firefox3.2?

Comment 11

8 years ago
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.

Updated

8 years ago
Duplicate of this bug: 507470

Comment 13

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

Comment 14

8 years ago
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

Updated

8 years ago
Flags: blocking-firefox3.6?
Flags: wanted-firefox3.6?
Flags: blocking-firefox3.6?
Duplicate of this bug: 535557

Comment 16

7 years ago
(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

7 years ago
(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

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

Updated

7 years ago
blocking2.0: --- → ?
status2.0: --- → ?
Does this patch highlight the full domain name or does it match the mockups from comment 17?
blocking2.0: ? → -
status2.0: ? → ---
Attachment #337861 - Flags: ui-review?(shorlander)
(Assignee)

Comment 20

7 years ago
(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.
Ooops, I didn't notice the datestamps :) Well, do we still want this as part of the Firefox 4 theme revamp?
(Assignee)

Comment 22

7 years ago
Created attachment 461211 [details] [diff] [review]
patch

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

Comment 23

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

Comment 25

7 years ago
(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.
Let's wait for Shorlander to tell us what it should look like.
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).
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
>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

7 years ago
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

7 years ago
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

7 years ago
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
Duplicate of this bug: 597270
Keywords: ux-visual-hierarchy

Comment 34

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

Comment 35

7 years ago
Created attachment 476580 [details] [diff] [review]
patch

updated to tip
Attachment #461211 - Attachment is obsolete: true

Comment 36

7 years ago
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):\/\/(?:[^\/]+@)?)([^:\/]+)
(Assignee)

Comment 37

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

Comment 38

7 years ago
Created attachment 476610 [details] [diff] [review]
patch

This is on top of the patch in bug 597769.
Assignee: nobody → dao
Attachment #476580 - Attachment is obsolete: true
Status: NEW → ASSIGNED
(Assignee)

Updated

7 years ago
Depends on: 597769
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.
(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.
(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

7 years ago
(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

7 years ago
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

7 years ago
What's the target milestone for this?
(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

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

Comment 47

7 years ago
Opera: http://my.opera.com/desktopteam/blog/2010/11/17/new-and-improved
Whiteboard: [sg:want] [parity-IE] [parity-chrome] → [sg:want] [parity-IE] [parity-chrome] [parity-opera]
Whiteboard: [sg:want] [parity-IE] [parity-chrome] [parity-opera] → [sg:want] [parity-IE] [parity-chrome] [parity-opera][target-betaN]
(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

7 years ago
Will this bug land in Fx4? I see [target-betaN], but no hard- or softblocker-tag?
(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.
(Assignee)

Updated

6 years ago
No longer depends on: 597769
(Assignee)

Comment 51

6 years ago
Created attachment 522352 [details] [diff] [review]
updated to tip

builds will be available at http://ftp.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/dgottwald@mozilla.com-4c4ad78fd4a6
Attachment #337861 - Attachment is obsolete: true
Attachment #476610 - Attachment is obsolete: true
Attachment #522352 - Flags: ui-review?(faaborg)
Attachment #337861 - Flags: ui-review?(shorlander)
Comment on attachment 522352 [details] [diff] [review]
updated to tip

granting just based on described functionality
Attachment #522352 - Flags: ui-review?(faaborg) → ui-review+
(Assignee)

Updated

6 years ago
Attachment #522352 - Flags: review?(dolske)

Comment 53

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

Comment 54

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

Comment 55

6 years ago
Created attachment 529440 [details] [diff] [review]
hidden pref and test added (r=roc, ui-r=faaborg)
Attachment #522352 - Attachment is obsolete: true
Attachment #529440 - Flags: review?(sdwilsh)
Attachment #522352 - Flags: review?(dolske)
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:admin@mozilla.org");
+  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 :)
Attachment #529440 - Flags: review?(sdwilsh) → review+

Comment 57

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

Comment 58

6 years ago
Created attachment 529664 [details]
screenshot (unredable url in address bar)
(Assignee)

Comment 59

6 years ago
http://hg.mozilla.org/mozilla-central/rev/63c46c761a92
Status: ASSIGNED → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 6

Comment 60

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

Comment 61

6 years ago
The change looks very good on me:

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

thanks for check-in.
(Assignee)

Comment 62

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

yep

Comment 63

6 years ago
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

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

Comment 65

6 years ago
(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

6 years ago
Good enough for me, how do I enable this feature in Firefox 4.0.1?
(Assignee)

Comment 67

6 years ago
> 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

6 years ago
The builds link is dead, any new link? 


Thanks

Comment 69

6 years ago
(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/

Updated

6 years ago
Depends on: 654411

Comment 70

6 years ago
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

6 years ago
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.
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

6 years ago
Sorry, I pasted it on the wrong browser tab...

Comment 74

6 years ago
Post number 70 is related though.
Depends on: 654809
Depends on: 654729

Comment 75

6 years ago
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.
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

6 years ago
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

6 years ago
(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

6 years ago
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

6 years ago
(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

6 years ago
Created attachment 530256 [details]
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).
Verified on: 
Mozilla/5.0 (Windows NT 5.1; rv:6.0a1) Gecko/20110505 Firefox/6.0a1
Status: RESOLVED → VERIFIED

Updated

6 years ago
Depends on: 659693

Updated

6 years ago
tracking-firefox6: --- → ?

Updated

6 years ago
tracking-firefox6: ? → +

Updated

6 years ago
Depends on: 660391

Updated

6 years ago
Whiteboard: [sg:want] [parity-IE] [parity-chrome] [parity-opera][target-betaN] → [sg:want] new feature, potential backout for 6
(Assignee)

Updated

6 years ago
Whiteboard: [sg:want] new feature, potential backout for 6 → [sg:want] new feature, potential backout for 6 [parity-IE][parity-chrome][parity-opera]

Comment 83

6 years ago
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.
Whiteboard: [sg:want] new feature, potential backout for 6 [parity-IE][parity-chrome][parity-opera] → [sg:want] [tracking+ because this is new feature in 6] [parity-IE][parity-chrome][parity-opera]
Depends on: 661422
(Assignee)

Updated

6 years ago
No longer depends on: 661422
(Assignee)

Updated

6 years ago
No longer depends on: 256773

Comment 84

6 years ago
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.)
Whiteboard: [sg:want] [tracking+ because this is new feature in 6] [parity-IE][parity-chrome][parity-opera] → [tracking+ because it's new in 6] [sg:want] [parity-IE][parity-chrome][parity-opera]
(Assignee)

Comment 85

6 years ago
(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.

Updated

6 years ago
tracking-firefox6: + → ---
Depends on: 679720
Blocks: 680368
(Assignee)

Updated

6 years ago
Depends on: 685263

Comment 86

5 years ago
Is [sg:want] still needed?
Whiteboard: [tracking+ because it's new in 6] [sg:want] [parity-IE][parity-chrome][parity-opera] → [tracking+ because it's new in 6] [sg:want][parity-IE][parity-chrome][parity-opera]

Updated

5 years ago
Blocks: 689139

Comment 87

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

Updated

5 years ago
Depends on: 814850
(Assignee)

Updated

5 years ago
No longer depends on: 814850
You need to log in before you can comment on or make changes to this bug.