New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 292 users

Issue metadata

Status: Duplicate
Merged: issue 881694
Closed: Sep 7
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Chrome , Mac
Pri: 2
Type: Bug-Regression

  • Only users with EditIssue permission may comment.

Show other hotlists

Hotlists containing this issue:

Sign in to add a comment

Issue 881410: Incorrect transforms when stripping subdomains

Reported by, Sep 6

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/69.0.3497.81 Safari/537.36

Steps to reproduce the problem:
1. Enter any URL starting with "www.", for example,

What is the expected behavior?
The URL Bar should show ""

What went wrong?
The URL Bar shows ""

Did this work before? Yes 68

Chrome version: 69.0.3497.81  Channel: stable
OS Version: OS X 10.13.6
Flash Version:

Comment 1 by, Sep 6

"www" is now considered a "trivial" subdomain, and hiding trivial subdomains can be disabled in flags (will also disable hiding the URL scheme)


Comment 2 by, Sep 6

This is a dumb change. No part of a domain should be considered "trivial". As an ISP, we often have to go to great lengths to teach users that "" and "" are two different domains, and that they may not necessarily go to the same destination. The marketing world has done a lot of damage convincing people that "www" is both ubiquitous and non-essential, when in fact, for some domains, the use or lack of it can be quite important to getting to the correct location.

Comment 3 by, Sep 6

How will you distinguish vs ?

One takes you to the website about the project, the other goes to a random ntp server.

Comment 4 by, Sep 6

Labels: Hotlist-ConOps

Comment 5 by, Sep 6

This does appear to be inconsistent/improperly implemented. Why is www hidden twice if the domain is "www.www.2ld.tld"? I feel like the logic could be worked out better, eg
If the root zone is a 301 to the "www" version, removing "www" from the omnibox would be acceptable since the server indicated the root zone isn't intended for use. 

This isn't the behavior, though. If returns a 403 status, and returns a 404 status, the www version is still hidden from the user. The www and the root are very obviously different pages and serve different purposes, so I believe the should be some logic regarding whether or not www should be hidden.

Comment 6 by, Sep 6

Same behavior in Win 10, as expected...

Very Very bad decision! Exactly which authority considers it "trivial"? Every part of a domain is as critical as the rest, it's not exactly your responsibility to regulate names.

Comment 7 by, Sep 6

+1 for having a switch for this behavior, but -10 for special-casing 'www' in the default display. To be fair, I also hate pretty much all other forms of 'simplified' URL presentation. I think we should be arming people with knowledge and encouraging discerning behavior, and we should not be trying to gain the minimal benefit of a slightly shorter display string in exchange for compromising the correctness of something as fundamental as a phone number.

Comment 8 by, Sep 6

Another case I ran into:

"" displays as "".

Completely wrong.

Comment 9 by, Sep 6

An example of bad results from this in the wild: and are not the same site, and the first doesn't redirect to the second.

Comment 10 by, Sep 6

This is Google making subdomain usage decisions for other entities outside of Google. My domains and how subdomains are assigned and delegated are not Google's business to decide.

Comment 11 by, Sep 6

Components: -UI UI>Browser>Omnibox

Comment 12 by, Sep 6

Labels: OS-Chrome OS-Linux OS-Windows

Comment 13 by, Sep 6

--> Userfeedback

Dupe:  Issue 881335 .

Comment 14 by, Sep 6

re: Dupe:   Issue 881335  

Doesn't look like a dupe to me - looks like "same root cause" but not a dupe.  That bug, and all the google announcements linked in that bug have no mention of 'trivial subdomain' hiding.

Comment 15 by, Sep 6

While the cause of this issue and 881335 may be similar marking this as a duplicate does not make sense. (Especially if that implies that this issue will be marked as "Won't fix") Hiding portions of the domain name is about as hostile to the user as you can get. It means users cannot trust what they see in the address bar as truth and opens people up to the possibility of phishing attacks as well as extremely frustrating and hard to reproduce behaviors.

Comment 16 by, Sep 6

The domain is shown as, two totally different sites.

Comment 17 by, Sep 6

This will be a subdomain hacker/takeover dream.  It will be much easier to masquarade as a parent domain now.

Oh, and also hiding the trivial 'm.<domain>' is irritating - I often avoid (and in once case seek out) the m.<domain> due to the difference in content for the so-called mobile site.

Comment 18 by, Sep 6

The subdomains reappear when editing the URL so people type the correct one.  They disappear in the steady-state display case because this isn't information that most users need to concern themselves with in most cases.  I think this is an OK tradeoff even in the rare case when is not actually the same as  (Side note: like it or not, almost no real-world users will use such a thing correctly; configuring your server like this seems like a Bad Move even if it's technically legal, because people are going to access the wrong thing, and that has been true for some time and irrespective of Chrome's UI changes.)

There are multiple real bugs here though:

www.www.2ld.tld should become www.2ld.tld, not 2ld.tld (we should strip at most one m. and www.) should be left as-is, not (should only strip prefixes)

->jdonnelly to assign.

Comment 19 by, Sep 6

Also, on 69.0.3497.81 Mac, I have to click the omnibox *twice* for the https:// and www. prefixes to show up. At the very least I feel it should only require one click for the prefixes to show up.

Comment 20 by, Sep 6

Status: Assigned (was: Unconfirmed)

Comment 21 by, Sep 6

Summary: Incorrect transforms when stripping subdomains (was: "www." subdomain missing from URL)
@19: Changing things on focus turns out to feel much more frustrating in a lot of use cases (we tried both, plus a lot of other behaviors).

Comment 22 by, Sep 6

Is there a list anywhere of what mighty Google considers trivial?

Comment 23 by, Sep 6

Re: security, hacker/takeover

We have a domain that is on the Public Suffix List. We control the Public Suffix root (like .com, When someone registers the www-subdomain (like or or, will that be shown as the PSL root domain (like .com,,

How will people see that they are NOT on our site, but on a subdomain that is controlled by a third party?

Comment 24 by, Sep 6


> this isn't information that most users need to concern themselves with in most cases.
According to who? This is simply an opinion stated as a fact.

> I think this is an OK tradeoff even in the rare case when is not actually the same as
How rare is this case? Comment #9 shows that citybank has 2 different websites hosted at both those URLs. Comment #16 shows the same issue with Clearly, this case isn't as rare as expected.

> (Side note: like it or not, almost no real-world users will use such a thing correctly;)
That's unfortunately, just another opinion stated as fact.

Comment 25 by, Sep 6

I actually thought Chrome was malfunctioning. This decision seems totally arbitrary. Was there any research done to justify this decision, or was it the whimsy of a PM who thought it would be a cool UX thing?

Comment 26 by, Sep 6

Please revert this change, this is an alienation to every Web user, they need and have the right to know which URL are they visiting.

Comment 27 by, Sep 6

Enter into the address bar:

It shortens it:

WTF? How does ===

Comment 28 by, Sep 6

I just don't understand why. On my clock, if it's 12:00, I see 12:00 not 12. When I get a receipt and it's a dollar value, I see $2.00 not $2, when I enter phone numbers to call, the number I entered is what I see displayed: it doesn't reduce it by removing the country code, or the area code if unneeded, etc.

Everyone loses clarity and some users will lose time due to this, but we gain what? What is the benefit in hiding 4 characters?

Comment 29 by, Sep 6

As a web developer I am a little horrified that the decision was made to hide a portion of a URL that could potentially be pointing to a completely different server. Please revert.

Comment 30 by, Sep 6

(Edit for @28, after seeing @27 I notice it's not just 4 characters at the beginning of the url it's a lot more and at a much more serious loss of clarity. This is crazy the paths are not shortened they are completely changed).

Comment 31 by, Sep 6

Arbitrary half-cocked changes like this and the recent AMP stuff are really pushing me away from all of Google's services. This change has not been thought out well.

Comment 32 by, Sep 6

I believe this Wired article gives some perspective to this change:

They use altruistic arguments, but of course we can all see their business objectives as a search engine to get rid of the URL. This is probably just a first small step to reduce the importance/trust of the URLs.

Comment 33 by, Sep 6


> They disappear in the steady-state display case because this isn't information that most users need to concern themselves with in most cases.

If most users don't care (which I think is what this is getting to) and power users do care, what's the concern on keeping the subdomains then? This is just adding corner-cases where none are necessary, and means that if I want to know what URL I'm viewing, I won't be able to at a glance, I'll have to click to check.

Comment 34 by, Sep 6

Related to @27:

I also noticed, if you double click the omnibox while on, the cursor is at the wrong position. If you double click the omnibox to the right of the URL, it focuses the cursor here: http://www.example.www.exa| but it should be at the end of the .com.

I think the offset calculation for the cursor is wrong. Similarly if you double click the omnibox on top of the URL, then it also inserts the cursor at the wrong position.

Comment 35 by, Sep 6

Just to add, Safari also hides http(s) and www. From their address bar as well. Heck, they only show the domain name and hide the rest of the url unless you click to edit it.

On HTTP sites, Safari doesn't even show 'http://' when you edit the address bar. It is still copied to the clipboard though. Try it on

Comment 36 by, Sep 6

@jeffreyc / 35: Safari for desktop (at least) does not hide the www. It does hide the protocol though. I think you might be thinking of Safari for iOS.
114 KB View Download

Comment 37 by, Sep 6

If the objective is to make URLs less confusing an emphasize the main domain name, why not just render parts in gray or make the main part bold. Wouldn't that achieve the same goal without essentially breaking the internet?

Comment 38 by, Sep 6

Since this is essentially a security vulnerability, is Google going to get a CVE assigned for it? It would make it easier to help effected users make sure this is patched on their end.

Comment 39 by, Sep 6

This is a complete mess, please revert to the old good and nice state.

Comment 40 by, Sep 6

Here's another example where it goes very wrong. The site "" should not show up as "".

Very disappointed with this change.

Comment 41 by, Sep 6

@37 I tried to convince them to do that back in '08

Comment 42 by, Sep 6

-> tommycli@
some examples of bad stripping of subdomains on this thread

By the way, the stripping of the "m." host/subdomain on desktop platforms was confusing and problematic, I agree.  It was reported in  bug 875669  and fixed for Chrome 70.

Comment 43 by, Sep 6

Another 'me too'.  I can just see tech support screaming, there could be 2 completely dfferent websites that show as the same in the URL.  I'm also dreading the SQL certificate issue - not everyone uses wildcard certificates for good reason, may be separate infrastructure from

Comment 44 by, Sep 6

This is going to cause troubleshooting issues. For example, if a site is slow you might open up terminal and do a traceroute/ping/etc. Many sites use redirect services provided by their CDN, DNS provider, registrar, etc. to redirect to, so you definitely need to know which one.

Of course, someone technical enough to do that sort of troubleshooting will quickly learn to view the full URL, but imagine if you're helping a non-technical person over the phone: "What's the URL?" "" "Are you sure it's and not" "Yes." "Are you using Chrome?" "I think so." "Double-click the address bar and tell me if it changes." "It didn't." "Are you sure you double clicked? Do you see an http:// or https:// in front?" "Oh, wait, nevermind. Now it says" "Ok, great."

Hiding "noise" like the protocol and www from users is a good idea, but I hope you find a way to do it without obscuring important information. (I like the idea of just using really light text.)

Comment 45 by, Sep 6

Labels: Team-Security-UX Restrict-AddIssueComment-EditIssue

Comment 46 by, Sep 6

 Issue 881206  has been merged into this issue.

Comment 47 by, Sep 7

 Issue 881662  has been merged into this issue.

Comment 48 by, Sep 7

FYI from recently merged  issue 881662 :

Steps to reproduce the problem:
1. Attempt to visit:

What is the expected behavior?
Host is shown as ""

What went wrong?
Host is shown as ""

Comment 49 by, Sep 7

 Issue 838166  has been merged into this issue.

Comment 50 by, Sep 7

Mergedinto: 881694
Status: Duplicate (was: Assigned)
this discussion ended up veering, let's have the security discussion about elision at 881694

Comment 51 by, Sep 7

Issue 881979 has been merged into this issue.

Comment 52 by, Sep 8

Issue 881950 has been merged into this issue.

Comment 53 by, Sep 10

 Issue 882309  has been merged into this issue.

Comment 54 by, Sep 10

 Issue 882306  has been merged into this issue.

Sign in to add a comment