An option to show the full website's address and protocol

[CharmCityCrab]

What is the user problem or growth opportunity you want to see solved?

Fenix should display the full URLs including protocol (http://, https://, etc.) and "www" (When applicable) in it's address bar. Ideally, it would do so by default, but it seems like a user option would be a reasonable compromise if no consensus can be reached.

How do you know that this problem exists today? Why is this important?

People have talked about this issue and shown screenshots of Fenix elsewhere online.

It is important to show full URLs with protocols for several reasons.

The first reason, but least common issue is that https://www.example.com and https://example.com do not necessarily lead to the same page. They usually do, but not always. So, anything that does not show the www as a matter of course is potentially introducing an inaccuracy into the information flow to the user.

However, more so than that, it is important to keep full user visible URLs to preserve an open Internet accessible directly by all with a simple DNS lookup that doesn't limit the end user's ability to see what is really going on and concentrate power in the hands of search engines and web sites. The removal of protocols and www are a step in a potential progression that Google has talked about having continue until it doesn't show anything except the domain name, making "https://www.example.com/example/example.html" and every other unique page within the domain simply "example.com". Beyond that, we could just wind up with "example".

Mozilla's principles lead one to believe that they want to preserve an open Internet that empowers users to view as much information as they want and to explore the web whichever way they want to explore it with or without search engines, directly or via links, with Google or with DuckDuckGo, with Chrome or with Firefox, and so on and so forth.

Firefox has an opportunity here to be a strong counterweight to Chrome's attempt to lead the Internet into being essentially, from the user side, a series of "AOL keywords" and to be a stronger browser for people who want a deeper dive into the web browsing experience than what Chrome and Chromium-based browsers can offer them.

We also want to keep the door open to new protocols and to the revival of old protocols and for the user to be able to see those protocols and differentiate pages using them from existing protocols in their minds, which means we have to keep the idea of protocols alive in the minds of users and keep them in front of them even if the present era uses relatively few protocols. If eventually a different protocol arises that is better for some purposes than others, and a decision is made to support that alone with existing protocols, we need users to understand that "https://www.example.com" is different from "example://www.example.com" so the user can make informed choices and guard against phishing attempts.

Moreover, ultimately, hiding information from the URL is going to lead to AMP pages hosted by Google being indistinguishable from pages hosted on independent servers.

It is thus important to keep full URL information visible to the user- ideally by default, but as an option if default is not considered realistic for other reasons.

Having this feature will also help Fennec users who currently choose to have their browser display the protocol and URL transition to Fenix when the time comes. Going from Fennec to Fenix is going to be a dramatic change in general for some users, and feature parity, I would imagine, along with being a goal of the development team in general, will also reduce day one transition shock so that fewer people abandon the web browser when the change comes to the release channel. Users should feel that instead of a change to Fenix limiting them, that it allows them to everything they could do with Fennec and more.

Flagship phones often have mid-level PC specs in some areas now. 8 GB or 12 GBs of RAM is not uncommon, for instance. Screen size is increasing dramatically. Most browsers are still unnecessarily limited compared to desktop browsers. Firefox should be expanding rather than contracting what it can do on these devices. For many people now, a phone serves as their most used or only Internet capable device, and when features disappear from their phone's browser, that really does limit what they can do on the Internet in general in important ways.

A phone is no longer just a cut down quick reference-things-on-the-go type of device. People curl up with their phones for hours upon hours a day. When we reduce the information flow, user options, and the control that users have on their phones in ways that are not strictly required for useability, we are in a very real way limiting what the Internet and specifically the web can be for a lot of users.

Who will benefit from it?

Users. The Internet. Any company not named Google.

┆Issue is synchronized with this Jira Task

[notJerl]

Does setting browser.urlbar.trimURLs to false no longer work?

[CharmCityCrab]

Does setting browser.urlbar.trimURLs to false no longer work?

1. In the current beta, using about:config to set browser.urlbar.trimURLs to 'false' does not produce the desired result when the URL bar is at the bottom of the screen. In the instances when the bar, while being set to display at the bottom, flips to the top of the screen (Generally when touched and a keyboard pops up to allow one to enter a new URL- although possibly on other occasions as well), it does then, with that about:config setting, show the full URL, but only until the bar flips to the bottom again (after the conclusion of the direct keyboard entry interaction), at which point the protocol and the "www" are lost again even when the bar is showing.

2. The broader issue is that, last I heard, the plan was to make about:config unavailable to the release channel version of Fenix when it lands there, so whether an about:config tweak to allow this behavior works completely, partially, or not at all in beta isn't really going to matter to the end release/stable/gold product as things stand. If the release or stable version of Firefox is going to allow full URLs when Fenix hits stable, it will either have to allow full URLs by default, include a GUI option to enable full URLs that is independent of about:config, or include about:config (The latter would be a change from the plans that I had read about, albeit a very welcome one IMO).

[notJerl]

Interesting. If there's no about:config in Fenix, I will probably not be using Fenix at all. The existence of about:config is the entire reason why I use Firefox.

[kbrosnan]

about:config will not be a way to modify Fenix UI. Its usefulness will be limited to Gecko behavior.

[filips123]

I think protocol can be hidden because Firefox is web browser and main protocols for the web are http and https. There is also lock icon which notifies user if they use https it not.

In addition to this, Firefox should support automatic redirection to HTTPS version of website if website supports HTTPS.

Most other protocols won't even work in web browsers, but in case if they do in the future, they should display protocol name, because they are not main protocols for the web.

However, www and other subdomains should not be hidden, because they are important part of URL and can display different results. Also, once you click on URL bar to edit or copy URL, it should display whole URL, including protocol, so you can easily edit or share it with others.

[notJerl]

If there's no way to toggle this, there's a good chance I will not be using Fenix.

[ghost]

I was never with removing any part of the URL. I don't know why all browsers are following the "trend". Just see this issue: https://github.com/mozilla-mobile/fenix/issues/7077 by looking at the comments there it seems that they are not stopping at just removing the protocol http://, https:// and the website address part www. I don't know but if this keeps going we may see the address bar disappear entirely. Each and every part of the website address is really important because there's no shortage of fake, spam and phishing websites and the general avarage users will get definitely confused about it!

"Power users"/"advanced users" may be willing to read the exact webpage address each time but the general average user won't care about it! Just imagine if a phising website is trying to act like the original website here! Nowadays fraudulent actors have become so wise that it has become very hard spot what is original what is fake. And if the browser's start removing the important information then it'll lead to even more confusion!

But I also have to agree that the space on mobile the is limited, the address bar on mobile can't handle the full website address to be displayed at a glance. If we display the https:// and www. everytime then the actual web address might get even hidden.

Maybe some sort rules have to be set and make them known to most of the users, let's say if the site supports https://then the lock icon is displayed otherwise a crossed lock icon should be displayed and if the website starts with www. then it should also be hidden, then these will become common sense and some sort of standard would be set but apart from that nothing should be removed, I think. As users will come to know that the https and the www. part is always hidden (only the www. part and nothing else!) and if a site just supports http:// then a crossed lock icon is displayed. This common sense is really hard to achieve as every browser out there has to behave like this. And it'd be a surprise for the existing users too! This is something that Fenix already seems to be doing.

But perhaps we should just make the browser display the whole website address, it's not like web browsers on mobile always did hide parts of the address before, it's just a recent trend that Fenix also seems to be following. That's it!

Providing an option to switch Fenix to display the whole address is something that I don't think would be useful because the default behaviours matter and if Fenix team decides to make hiding parts of the website address then it won't be useful to general avarage users as they might not be willing to change any setting and they might just use the browser with its default settings. And it won't be useful to the advanced users either since they already know that full website address is something they can actually look at by clicking the address bar and they're always vigilant about what the URL is and if there's something wrong with it, so providing an option is redundant to advanced users.

I did try to add some ideas such as ability to scroll the website address in the address bar with issue #11074 but I'm not sure if this going to solve or introduce more problems to the existing problems. Fenix address bar's space is already limited but the issues like https://github.com/mozilla-mobile/android-components/issues/6429, https://github.com/mozilla-mobile/fenix/issues/11045 are going to introduce more icons in the address bar so even more scarcity of space in the address bar! I'm just not sure how to make/have a balance here.

Whoever is reading this comment I want you to make counter argument to my views and why you think something shouldn't be like this but the other way around. So we can all get a better understanding of this situation and come up with a solution that we can provide to Mozilla to consider.

Thanks.

P.S. And if possible please don't mark this comment as "off-topic" or something like that. I'm writing all of this with a lot of effort so please if possible appreciate it a little bit.

[CharmCityCrab]

What some of these comments that talk about removing only protocol or replacing it with icons and saying that hypothetical future protocols could always be included in their entirety if they become popular or significant enough to support in the browser to differentiate them from the unmarked http:// and https:// protocols, are, in my view, missing, is the browser's role in teaching and in shaping the way people understand the Internet.

If end-user visible protocols are eliminated, we will have whole new generations of people coming up in the world who don't know what a protocol is or who would not even think to look for one. In addition, existing users who may only be passingly familar with the concept could quickly forget. When one then goes to add a new protocol, people not only won't know what the new protocol is, they won't know what a protocol is in general, and may simply assume it's irrelevant, because that's what we will have taught them by implication, which of course leaves them poorly equipped to decide whether sites using new protocols are things they want to access, and open to phishing attempts if they don't understand what they're seeing because they've never seen protocols before. Thus, in the long-run, that oversimplification limits the potential uses and the security of the Internet as displayed in all browsers.

As a company attached to a non-profit fighting for the preservation of an open Internet and other principles, Mozilla in theory can take the long view here and keep including protocols. This will equip Firefox users to better understand the protocols they access today, and how protocols that may arise in the future may be different, and to benefit from the security that comes from that information.

When a browser eliminates access to something, it implicitly tells the user "That's not important. You don't need to know it." and then people stop knowing it as time passes.

Even though including it is not actually literally teaching it, users who see it there every day who know what it is will be less likely to forget, and new Internet users or users new to good browsers may see it and look up the answer somewhere to inform themselves. When it's hidden, an out of sight, out of mind phenomon develops, and after enough time passes, the concept is gone forever, and the wheel must be reinvented if people decide they want to use a wheel after all in an era where no one remembers the wheel or grew up with the wheel.

That metaphor works on another level, which is that many web browsers are turning into self-driving cars, but the new automated driver is actually not just neutral automation, it's a company or companies with a profit-centered agendas that don't always have the user's best interests or the long-term best interests of an open web at heart. Mozilla's blend of foundation and corporation allows it to be different and to let the users steer themselves if they choose to, and keep in practice in case the automation no longer works for them or doesn't work at all on certain types of future highways.

I think philosophically anything that cuts end users off from full URLs is a bigger deal than it may first appear. It's not the web as we know it if we just get whatever part of the URL a browser thinks we should see instead of having full addresses. That's a real shift in terms of transparency to the end user about what is happening in their browsers when they do certain things.

[ghost]

I agree what you are saying but the only thing I'm worried about is; let's say the website is https://www.wikipedia.org/ and Fenix's address bar is very short it also accompanies "Reader Mode" icon and in future it might house the "Container" icon in the address bar: https://github.com/mozilla-mobile/android-components/issues/6429

So the problem here is that if the address bar contains all those icon and is already short in space then how the Fenix is going to display all of the https://www.wikipedia.org/ address at a glance? I don't have a solution here.

There are some consideration to make the address bar a bit bigger by integrating the security lock icon and the shield icon of tracking protection here: https://github.com/mozilla-mobile/fenix/issues/11812

And Fenix already displays the full address bar when the security lock icon is clicked or the address bar is clicked.

The problem here is that the amount of space available in the address bar and how utilise that small space to display the website address so that users do not end with an address like this https://www.wikipe... in the address bar instead of the wikipedia.org/.

Can you think of any solution to this problem? I honestly am trying really hard to come up with an idea to solve this address bar issue but nothing is striking my in head yet. As I said, I tried with this #11074 but nothing that will actually solve the problem is coming up in my head.

[Dunexus]

If end-user visible protocols are eliminated, we will have whole new generations of people coming up in the world who don't know what a protocol is or who would not even think to look for one.

Most of current users don't know what protocols are and don't want to learn much about them. Someone like my parents barely know that the "s" of https means there are in a secure context. If this is replace by a lock, it would provide the same information for them. I think most users are in this situation.

[CharmCityCrab]

As far as the issue with the length of URL bar being a problem if we combined full URLs with "Reader Mode" and "Container" icons on the same line of the screen, there are two potential ways to get around that.

The first way would be not to include reader mode and container icons as part of UI for the screens that can load pages at all. Instead, they could be listed with all the add-ons that the user has installed on a separate screen.

The other possibility is that, given the increase in vertical screen space on newer Android phones, which are not only bigger in general but are shaped to be taller and skinnier, a(n optional) user toolbar similar to the desktop could be created for those type of icons.

Failing either of those two options, it might be worth thinking about whether reader mode and containers are something that really need to be on by default and displayed prominently. Maybe they should be something people enable if they want them, or even extensions (Albeit officially recommended highly promoted ones). I am all for expanding browser functionality, but not at the expense of the information flow to the user from a browser's most basic functions (browsing and loading pages).

I don't think it has to come to that type of either/or decision, though. One of the two options I mentioed may be viable, and if neither is, there are probably more ways of doing it that aren't readily apparent to me at 5am. :)

[CharmCityCrab]

Regarding users who don't know what protocols are and have no desire to learn, including protocols does not make life any more difficult for them. They could still get to sites in the same ways they would without the protocols being displayed.

I would also tend to think that while Firefox should welcome all users, that it's target audience is not or probably should not be incurious people who like things dumbed down. I don't mean that an insult, I am just saying that there are plenty of browsers that serve that market and it is hard to gain marketshare in that market because it limits how much you can lean into being different and present reasons why your experience is better suited to some people than Google Chrome's experience, etc..

Firefox should not be completely inaccessible to non-power users, of course, but I think there is plenty of room between that extreme and the opposite perch Chrome likes to sit on, and that space is available for Firefox to occupy.

[hkaancaliskan]

IMO this could be a preference in settings and people will just select what they want. Everybody will be happy.

[filips123]

What some of these comments that talk about removing only protocol or replacing it with icons and saying that hypothetical future protocols could always be included in their entirety if they become popular or significant enough to support in the browser to differentiate them from the unmarked http:// and https:// protocols, are, in my view, missing, is the browser's role in teaching and in shaping the way people understand the Internet.

Then you should also show website's IP address. And all detailed network communication. Including all DNS and TCP requests. How would users be able to browse the web without knowing all details how their network works?

[CharmCityCrab]

filips123 said "Then you should also show website's IP address. And all detailed network communication. Including all DNS and TCP requests.".

I actually wouldn't be opposed to a "Learn More About This Website" thing in the settings or dropdown menus (Though I believe protocol and www should be in the address bar by default, ideally, or, if a compromise, as a user configurable preference that puts them on in the URL bar where the default could be set to whatever Mozilla deems best- not hidden away like that.) or something that includes some of the extra information you mention (I'm envisioning something like the way the UBlock Origin interface on mobile that instead includes site IP addresses and the details of traffic between the browser and the site). If you're serious about that (I get the feeling you're not, but just in case.), though, please open a separate issue as it is beyond the scope of this issue. I'll even give it a thumbs up or something if it's presented seriously and as something you can access in settings or a dropdown menu and not with that information directly on the UI displayed above or below the website loaded. I'd also be interested in it in extension form if the APIs are available to do it. That's not what this issue is about, though.

Also, I would say that anything that monitors all network requests from the device and not just from the browser is not only beyond the scope of this issue, but beyond the scope of a browser or a browser extension. That would probably have to be a separate app. In fact, those apps exist for desktop (Wireshark, etc.). I am not sure if there are Android apps that do that, but there certainly could be.

Anyway, trying to move this back to the topic of this issue-

One reason protocol and www are different from your examples is that they have traditionally always been included in the address bar on bars going all the way back to the Mosaic browser, then Netscape Navigator, and, finally, most versions of Firefox.

In fact, right now, probably thanks to changes in about:config (Which, again, won't exist in the stable version of Firefox once it moves from a Fennec base to a Fenix base), my versions of Firefox on both desktop and mobile (Which I have made the default browsers on each platform on my devices) include both the protocol and the www.

I think people perceive it differently when information they've typically traditionally been given, and which they are using to this day due to options, are taken away from them, relative to just a failure to include information that has almost never, if ever, been included in the browser's UI. Its also much easier to display protocol and www in the URL bar than it is the other information you describe (Though, as I said, it actually might not be a bad idea for a settings type menu).

Since some popular Android browsers don't include protocol or www, and others are talking about eliminating it, this is an area where Firefox has the opportunity to carve out what may be close to an exclusive niche where everyone who cares about it will choose Firefox, and everyone who doesn't can still use Firefox and ignore it, as websites would still load if they entered "example.com", just as they do on versions of Firefox that have the protocol and www do today, even though the full protocol would be displayed while and after they load. It's value goes beyond the practical stuff and sends a strong signal about Firefox's values and mission.

[buttercookie42]

Fennec scrolled the URL such as to right-align the TLD (plus one or two extra characters to give a hint whether the URL has additional bits or actually stops right after the TLD) with the right edge of the URL bar by the way, and then you could also scroll the URL left or right (though the latter wouldn't quite mesh with swiping to change tabs, which a number of other people also desire).

[liuche]

We removed this in #7077 due to limited horizontal space in the urlbar. https/http is designated by the lock icon.

[filips123]

What about www and other similar subdomains? They are not indicated by any icon.

Also, if lack of horizontal space is a problem, you could make that www is displayed but URL is aligned to start of main domain. Then, users can just scroll to see www. Ok, that would not work.

[cadeyrn]

What about www and other similar subdomains? They are not indicated by any icon.

www. is not shown, but other subdomains are shown so I have no idea what you mean bei "other similar subdomains". And "www." is not relevant at all in… I guess… 99,9999 percent. Also you see the protocol and the www. when clicking the address bar, it's only hidden if the address bar is not active. I really appreciate the current solution and vote against a change because I don't see any advantage in the suggestion at all.

[s-ankur]

I am confused by this discussion as clicking on the lock icon shows the full url including the protocol and the www subdomain. Also, how is the current behavior different from "URL is aligned to start of main domain"? Because when you click on the address bar, you can see the whole url as well

[dessalines]

I'm also confused about why this is an issue. I just checked, and when you click the url, it shows the full url.

Are people really complaining about a shortened url for tabs on mobile?

[yoasif]

I don't really understand why www has to be shortened away when we already know that it is a significant part of URLs. Interestingly, while Fenix proposes to hide www, mozilla continues to redirect users to www.mozilla.org - I don't point that out to make a "someone didn't get the memo" joke, but rather to show that even Mozilla's webmaster doesn't feel that the www is insignificant -- if it were, it would be dropped there.

FWIW, GitHub actually doesn't use www, so the URL in Firefox desktop (where I am typing now) and Fenix is consistent - not so for Mozilla.

Ultimately, I don't think it is worth making this change (for www) - if publishers believe that their sites should display without a www, they are well within their power to do so. As it is, the inconsistent URL display and limited saved screen real estate hardly seems worth it.

See the comparison to Fennec (dropping the https://):

Hardly any space at all is saved, and this is on a device that is nearly the worst case scenario for a device running Fenix (small screen).

[ashneo76]

Honestly, this is a terrible and self-centered UX decision. Replacing a protocol that clearly states what it is and what it does hides the fact that you are visiting a website and not an app.

The number of times that I have to explain to people, my parents, siblings, cousins, etc. how to differentiate an app from a website or a secure vs non secure is ridiculous.

And no, icons that make sense to select few group of people is not the answer. A gear icon can mean anything to anybody. Sure a green lock is better than a "gear" icon or a "hamburger icon" or an "overflow" icon. Those don't mean much to people not programming or designing UX everyday, like my parents.

And finally, www is a significant part of a website. Technically, it is just as significant as any other subdomain. Hiding it away, is like creating a special case exception for a useless case.

In short, this move, from a browser that is supposed to lead the way, is quite frankly, infuriating.

[TRPB]

I realise this is a github issue, not a discussion of the merits of the change, but since that seems to be what it's become I'll put up some counter arguments. I think hiding www and http/https are a smart move as long as it never hides any subdomain other than www

• On mobile horizontal space is limited and this is clutter that matters 0% to a vast majority of users.

• The domain is the most important part of the URL and deserves to be first. By reducing clutter users may identify phishing scams more easily

• www is a relic of the 90s and it would be better if websites stopped using it entirely. This site: http://no-www.org/ has been around for the best part of 20 years explaining why. If you want to make a case for www for websites then you also need to make a case for email addresses being in the format user@mail.example.org rather than user@example.org from the perspective of a user (Yes, technically it's different because mail uses a different dns record so your http server and mail server can be different on the same domain name, but users do not care about that stuff). From a user's perspective, www is this. From a technical perspective, www implies the protocol but that's redundant because http or https is the protocol. https://www is effectively repeating the same information twice to users.

• Let's face it, although I don't have the exact numbers, most domains with an A record set will be hosting a website and possibly a mail server and little else users would care about (There might services like cpanel and/or ssh, but I'm talking about a user's perspective).

• For any website, if someone types in the domain name, I want them to land on the website and not have to remember www. Similarly if the user does add www they should also land on the website. As such, www is redundant because www.example.org subdomain is a CNAME of example.org. There are websites that handle domain.com and www.domain.com differently but that's needlessly confusing to users and I'd argue it's a problem of the web developer, not the browser. And the problem exists whether or not the browser hides www.

• Most users do not understand or notice the difference between http and https. These are redundant. For 20+ years users have been told to look for the padlock (And I'd wager that moving this around the browser window and changing the colour causes more confusion than removing https from the address bar). Padlock vs padlock with a solid red line through it is clearer to users than http/https which is meaningless to them.

• Any user interaction with the URL uses the full URL anyway.

Personally I'd like to see this decluttering happen on the desktop as well. That said, there should be a setting in about:config or somewhere to enable it for those users who want to see this information.

Hardly any space at all is saved, and this is on a device that is nearly the worst case scenario for a device running Fenix (small screen).

They swapped out the protocol for a button with privacy controls. The privacy controls are going to be more useful to users than seeing https in the address bar.

[blunden]

@TRPB Why do you think that browsers should get to decide which subdomains to show and which ones to hide? They are different DNS records that potentially point to completely different IP addresses. Even if they resolve to the same IP, the widespread use of reverse proxies mean that they can easily point to different backend services. Whether they don't in a lot of cases doesn't mean you can always assume that they do.

This needs to be an option at least. Besides personal preference, some of us work in fields (e.g. cyber security) where misinterpreting the URL is problematic or would add extra steps to our work flow.

[TRPB]

@TRPB Why do you think that browsers should get to decide which subdomains to show and which ones to hide? They are different DNS records that potentially point to completely different IP addresses. Even if they resolve to the same IP, the widespread use of reverse proxies mean that they can easily point to different backend services. Whether they don't in a lot of cases doesn't mean you can always assume that they do.

None of this matters to users. Everyone making points like this is making them from the perspective of a web developer. Users don't know or care about the back end architecture of the site. To a user www.site.com and site.com should be equivalent, if you want to design your site otherwise, that's up to you but don't be surprised when you confuse users.

[blunden]

@TRPB Why do you think that browsers should get to decide which subdomains to show and which ones to hide? They are different DNS records that potentially point to completely different IP addresses. Even if they resolve to the same IP, the widespread use of reverse proxies mean that they can easily point to different backend services. Whether they don't in a lot of cases doesn't mean you can always assume that they do.

None of this matters to users. Everyone making points like this is making them from the perspective of a web developer. Users don't know or care about the back end architecture of the site. To a user www.site.com and site.com should be equivalent, if you want to design your site otherwise, that's up to you but don't be surprised when you confuse users.

So I am not considered a "user" of the browser I use? Good to know...

Just because a user is a web developer (or technical user) doesn't make their opinion or use case invalid. This change is forced upon technical users with no way to revert it. In that sense, it's a very Apple move and I'm surprised nobody has used the word "courage" in this comment thread yet.

It's up to me to confuse users if I want, not up to the browser to misrepresent the host part of the URL. There is nothing in the standard that says that "www.site.com" and "site.com" need to be the same.

[TRPB]

So I am not considered a "user" of the browser I use? Good to know...

You are in a tiny, tiny minority of a web browsers user base. And as I said, mozilla should implement a setting to allow showing the full URL for people who do want it visible.

It's up to me to confuse users if I want, not up to the browser to misrepresent the host part of the URL. There is nothing in the standard that says that "www.site.com" and "site.com" need to be the same.

And it will still work exactly the same way whether or not firefox chooses to show or hide www.

[blunden]

So I am not considered a "user" of the browser I use? Good to know...

You are in a tiny, tiny minority of a web browsers user base. And as I said, mozilla should implement a setting to allow showing the full URL for people who do want it visible.

It's up to me to confuse users if I want, not up to the browser to misrepresent the host part of the URL. There is nothing in the standard that says that "www.site.com" and "site.com" need to be the same.

And it will still work exactly the same way whether or not firefox chooses to show or hide www.

Based on Firefox having a browser market share barely reaching a double digit percentage, it's not unreasonable to assume that the more technical part of the user base is larger than for other browsers. I'm glad that we can agree on the need for a setting to allow users to disable this "feature" though. 🙂

No, it will not work the same because it becomes very confusing and tech support becomes a huge hassle. Also, I've managed to end up with incomplete URLs multiple times when copy pasting from Chrome's address bar since their change, even though that shouldn't happen.

[TRPB]

No, it will not work the same because it becomes very confusing and tech support becomes a huge hassle. Also, I've managed to end up with incomplete URLs multiple times when copy pasting from Chrome's address bar since their change, even though that shouldn't happen.

That's a browser bug then and needs to be fixed, but it doesn't really affect the underlying argument. Though it wouldn't happen at all if your site didn't differentiate between www.site.com and site.com, like users expect.

edit: The fact that this is a tech support headache for you shows that users expect them to be the same. Try combining them and see how much money you save on otherwise wasted time at tech support.

Regardless of whether you choose to do that, some users are in the habit of typing www and some are in the habit of just typing the domain. Showing or hiding www is not going to make any difference to the number of users who end up on the wrong page because you designed your site with a self imposed technical limitation taking precedence over your users.

I'd argue it's very bad practice to treat domain.com and www.domain.com differently on ports 80 and 443. This is going to be a bigger problem for users on your site than firefox or chrome choosing to hide www.

Users of your site will think that www and no www versions of the site are equivalent. But they thought that anyway because it's true for all the other sites the use regularly.

[zakius]

So I am not considered a "user" of the browser I use? Good to know...

You are in a tiny, tiny minority of a web browsers user base. And as I said, mozilla should implement a setting to allow showing the full URL for people who do want it visible.

It's up to me to confuse users if I want, not up to the browser to misrepresent the host part of the URL. There is nothing in the standard that says that "www.site.com" and "site.com" need to be the same.

And it will still work exactly the same way whether or not firefox chooses to show or hide www.

Based on Firefox having a browser market share barely reaching a double digit percentage, it's not unreasonable to assume that the more technical part of the user base is larger than for other browsers. I'm glad that we can agree on the need for a setting to allow users to disable this "feature" though. 🙂

No, it will not work the same because it becomes very confusing and tech support becomes a huge hassle. Also, I've managed to end up with incomplete URLs multiple times when copy pasting from Chrome's address bar since their change, even though that shouldn't happen.

technical users on desktop left when quantum disaster happened

Fenix can become a great mobile browser but it will never be Firefox just like Fennec never was, luckily most of quantum specific issues don't matter on mobile but tendency to remove everything that may confuse more than 1% of users does

[yoasif]

@TRPB Why do you think that browsers should get to decide which subdomains to show and which ones to hide? They are different DNS records that potentially point to completely different IP addresses. Even if they resolve to the same IP, the widespread use of reverse proxies mean that they can easily point to different backend services. Whether they don't in a lot of cases doesn't mean you can always assume that they do.

None of this matters to users. Everyone making points like this is making them from the perspective of a web developer. Users don't know or care about the back end architecture of the site. To a user www.site.com and site.com should be equivalent, if you want to design your site otherwise, that's up to you but don't be surprised when you confuse users.

@TRPB We'd be the ones confusing users here because going to www.domain.org and domain.org go to two different pages, but the browser always shows domain.org. There is no way for users to figure out what is going on because their browser is lying to them.

This isn't a stylistic choice, it is basically a bug.

[TRPB]

We'd be the ones confusing users here because going to www.domain.org and domain.org go to two different pages, but the browser always shows domain.org. There is no way for users to figure out what is going on because their browser is lying to them.

But users do not know generally the difference between domain.org and www.domain.org. Some users will want to visit your site and type domain.org others who are in the habit of typing www will type www.domain.org. This problem already exists, you just don't see it because people who type the 'wrong' domain end up in the wrong place. Users expect www.domain.org and domain.org to be the same.

You can't expect users to remember that your site functions differently to every other site they use. You designed your site poorly, it's not your user's fault for not understanding your non-standard back-end configuration.

[yoasif]

We'd be the ones confusing users here because going to www.domain.org and domain.org go to two different pages, but the browser always shows domain.org. There is no way for users to figure out what is going on because their browser is lying to them.

But users do not know generally the difference between domain.org and www.domain.org. Some users will want to visit your site and type domain.org others who are in the habit of typing www will type www.domain.org. This problem already exists, you just don't see it because people who type the 'wrong' domain end up in the wrong place. Users expect www.domain.org and domain.org to be the same.

You can't expect users to remember that your site functions differently to every other site they use. You designed your site poorly, it's not your user's fault for not understanding your non-standard back-end configuration.

You seem to think I am speaking from the perspective of the webmaster of the site - I am not. Browsers that hide www indiscriminately are working against end users by not helping them navigating what you consider to be hostile user experiences from webmasters.

Why can't I expect my user agent to help me navigate this circumstance instead of lying to me about the page that I am on?

[TRPB]

Why can't I expect my user agent to help me navigate this circumstance instead of lying to me about the page that I am on?

It does. If you type domain.org and there is no A record, it looks up www.domain.org instead. Because, like users, it expects them to be the same.

There is no reason to have different sites on www.domain.org and domain.org. You can choose literally any other subdomain you like for the second site and it won't result in confused users.

If they differ, some users will end up on the wrong site. This is a bug on the websites. The fact that firefox now obscures this bug is not really firefox's problem. It's like developing a site with flash then complaining when firefox drops support for it. It's not firefox's fault you implemented your project in an outdated solution that's poor for your users.

[yoasif]

Why can't I expect my user agent to help me navigate this circumstance instead of lying to me about the page that I am on?

If they differ, some users will end up on the wrong site. This is a bug on the websites.

There is no bug on the website. It might not be what you want to see, but it is the browser that is hiding the page you are on that is the buggy one.

You said earlier that this is "non-standard". No it isn't. It is an edge case. But it is an edge case that Fennec and Firefox desktop handle perfectly well, and Fenix and Chrome actively screw it up.

If this is truly a bug or non-standard, shouldn't we be working at the DNS level instead? Why not send out a message to IETF to get some vendor buy-in, put out a deprecation notice among browsers, and make www a relic of the past?

[cadeyrn]

but it is the browser that is hiding the page you are on that is the buggy one.

No. You don't have to like it but to say it's a bug is simply wrong, just like "browsers that hide www indiscriminately are working against end users". No, it's not "indiscriminately" at all and it's not true that this it's "against end users". For me it's clear that the opposite is true. Of course you don't have to agree that it's a good decision but in my opinion it's not okay to say "it' against the end users" because this claim includes that Mozilla has bad intentions. But it's a fact that "www." is not relevant at all in almost every case (only exceptions!), it's a fact that it's only hidden in the not focused address bar to have more space for the URL so that it's easier to see the relevant (!) part of the URL (and that's a user benefit!) and it's a fact that you still see the full URL after clicking the address bar.

I fully agree with @TRPB.

[TRPB]

If this is truly a bug or non-standard, shouldn't we be working at the DNS level instead? Why not send out a message to IETF to get some vendor buy-in, put out a deprecation notice among browsers, and make www a relic of the past?

This would be a good idea but the effort required to do this would outweigh the benefits. Sites which are just out there sitting idle for decades might even stop working entirely if www. no longer worked at all so it's probably not worth going that far. But a de-facto standard already exists. Sure it doesn't have an RFC number, but user expectation is there and the vast majority of sites follow it.

Fact: Users will type the domain. Some users will add www and some wont. Result: Some users will end up on the wrong site if domain.org and www.domain.org are different websites. This is an indisputable fact and this is a usability issue on the site in question where only the owner of the site has the ability to fix it.

A site owner who ignores usability issues on their own site is not in a particularly strong position when complaining about knock on usability issues created in the browser, which only exists in this edge case due to an issue which is easily resolved by fixing the underlying usability issue on the site itself.

[yoasif]

If this is truly a bug or non-standard, shouldn't we be working at the DNS level instead? Why not send out a message to IETF to get some vendor buy-in, put out a deprecation notice among browsers, and make www a relic of the past?

This would be a good idea but the effort required to do this would outweigh the benefits.

How so?

Fact: Users will type the domain. Some users will add www and some wont. Result: Some users will end up on the wrong site if domain.org and www.domain.org are different websites. This is an indisputable fact and this is a usability issue on the site in question where only the owner of the site has the ability to fix it.

Yes, it is a usability issue that is exacerbated by browsers that actively hide when they are on www.domain.org, instead reporting that they are on domain.org. How is the the browser helping this usability problem? Hint: It is not. It is actually making it worse.

but it is the browser that is hiding the page you are on that is the buggy one.

No. You don't have to like it but to say it's a bug is simply wrong, just like "browsers that hide www indiscriminately are working against end users". No, it's not "indiscriminately" at all and it's not true that this it's "against end users". For me it's clear that the opposite is true.

It is indiscriminate as in Fenix will remove www from all domains. That is lacking in discrimination. This isn't false, it is factual. As far as whether it is against end users, that is more of a value judgement, but I argue that it works against end users who would be confused by visiting a site with a www in the domain on Fenix, attempting to visit the same domain on Firefox desktop, and being taken to a different page. I believe that this works against end users.

Of course you don't have to agree that it's a good decision but in my opinion it's not okay to say "it' against the end users" because this claim includes that Mozilla has bad intentions.

This may be due to a language barrier but that is not at all what I said.

You have 👎 a bunch of my comments in this bug (which is totally fine of course), but I also noticed that your own web page includes a www. Why? If it is so bad and as @TRPB might argue, "non-standard", why have you (and Mozilla and Google) not removed the www from these sites? Why must the browser do what you will not?

I'll likely stop posting here as I am sure the team is already annoyed and I tried to make my best contribution to this bug as I could (and as I think you know @cadeyrn, I try to contribute in a positive way in this repository). In the grand scheme of things, it is a minor thing, but I truly feel that if this team is serious about this, perhaps some cross-browser conversations about doing this as a benefit to the web is in order, rather than changing this in the browser that result in confusion with limited benefits (we had both https and www in Fennec for years, and there was no great outcry for removal).

This doesn't feel to me like a "nice to have" it feels superfluous and unnecessary. I truly wish the same people who want to remove the www from domains lobby for it it on their own web presences, as a bottom up approach instead of obfuscating what exists from end user browser experiences. Then there would be no controversy whatsoever. The browser is showing the domain as it exists and all is well with the world (better, in fact, because you have some more pixels on your screen every time you browse that domain).

[TRPB]

Yes, it is a usability issue that is exacerbated by browsers that actively hide when they are on www.domain.org, instead reporting that they are on domain.org. How is the the browser helping this usability problem? Hint: It is not. It is actually making it worse.

But this is the Flash argument: "Firefox stopped supporting flash, therefore it's Firefox's fault my website stopped working". Ending flash support isn't helping solve the underlying usability problems that exist on websites using flash become more user friendly, it's actively making it worse!

In this instance, it's a minor additional inconvenience to users who are on a handful of websites which are already actively making things inconvenient for them. It doesn't break their bookmarks, it doesn't stop the site working, it doesn't stop them seeing the full URL when they share it with their friends, it just tidies up the interface a little. And for the other 99.99% of websites out there, there is no underlying issue to exacerbate. Seems like a fair trade-off to me.

[yoasif]

Yes, it is a usability issue that is exacerbated by browsers that actively hide when they are on www.domain.org, instead reporting that they are on domain.org. How is the the browser helping this usability problem? Hint: It is not. It is actually making it worse.

But this is the Flash argument: "Firefox stopped supporting flash, therefore it's Firefox's fault my website stopped working". Ending flash support isn't helping solve the underlying usability problems that exist on websites using flash become more user friendly, it's actively making it worse!

I don't really understand this analogy, Flash was never standard, and Adobe deprecated it. IETF has not made any announcement to ensure that www.domain.org and domain.org must be identical from all user agents.

[CharmCityCrab]

Can we all agree that websites Hypertext Transfer Protocol and Hypertext Transfer Protocol Secure are the protocols we are using when we view sites with http:// and https:// at the beginning of them? Can we further agree that whether it's widespread or not, and whether it's a good idea or not, there are the occasional websites that connect to different places when visiting https://www.example.com and https://example.com?

If these things are true and these things happen, then a web browser that fails to display those elements of the URL are not providing the end user with a full true and accurate URL. They are providing the end user with just the parts of the URL that the browser developers think will be relevant to the majority of users' experience. In doing so, they are abandoning important principles and going further down the path of the browser moving towards a walled garden experience ala AOL in the 90s and away from being a tool to access the open web without imposing what essentially is an editorial judgement as to what Mozilla feels they should be told and what Mozilla feels is not worth their time.

I expounded at length on some other issues this creates, but, in the end, this should be a very easy question for web browser created by a corporation that operates for a foundation to carry over money from year to year and is supposed to value principle over profit. The principles Mozilla exposes aren't "Simplify Everything and Don't Let the User See What's Going On if We Don't Think They Need to Know", they are about things like providing the maximum possible amount and information and control to the user and acting as a neutral gateway instead of a dumbed down corporate curator.

If Mozilla's principles are it's ethics, than what they are doing here in eliminating this information is wrong.

This is not the right thing to do, and it provides an awful example to companies like Google that have been pushing in the direction of eliminating URLs entirely. This helps them do it.

Look, we all hope that Firefox regains some of it's lost marketshare (Provided it doesn't continue to lose it's way with more decisions like this), but if it goes down (And the massive layoffs announced today along with sinking marketshare make that seem like something that is possible in the next years, or at least make it seem like if it continues it may as a collaboration between various Linux distros and open-source Windows compatible software makers.), what do you want it's legacy to be? Principled Microsoft/Google alternative that provided maximum information and choice to the end user? Or Chrome wannabe?

Reducing this to practical issues is ignoring the symbolism that is inherent in a move like this. It's an issue that Mozilla, which talks about it's principles in almost every press release it issues, should be thinking about. And if they think about it that way, it's an obvious decision- include protocol and include "www" (where applicable). Don't cave to the least common denominator.

[yoasif]

FWIW, I am not concerned about the removal of http/s and I agree with @liuche that the lock icon suffices to disambiguate between the two.

[CharmCityCrab]

In fact, it occurs to be that the current Mozilla logo is literally "Moz://a". It includes a pseudo-protocol of "Moz". It's right there on it's webpages and in it's press releases.

Yet, they are now pushing a web browser that doesn't include protocols. What's the thinking there? "Protocols: Important for logos, not important for URL bars"? Come on, folks. This project is supposed to stand for something. It's right there in your logo.

[TRPB]

I don't really understand this analogy, Flash was never standard, and Adobe deprecated it.

But this is a very web developer view. From a user's perspective, their favourite website suddenly stopping working is instantly fine with it when someone tells them "Well it was deprecated!".

IETF has not made any announcement to ensure that www.domain.org and domain.org must be identical from all user agents.

But this is how the vast majority of sites work. And this is the expectation from users. It doesn't matter if it has a proper standard behind it.

Reducing this to practical issues is ignoring the symbolism that is inherent in a move like this. It's an issue that Mozilla, which talks about it's principles in almost every press release it issues, should be thinking about. And if they think about it that way, it's an obvious decision- include protocol and include "www" (where applicable). Don't cave to the least common denominator.

I don't think that's what's happening here. Firstly, padlock icons are displayed so the user can differentiate between HTTP and HTTPS, so that's a non-issue. And in 99.9% (Probably more) of cases www is completely irrelevant because non-www and www domains function identically. Sure, there are some sites that do this but a user will never remember that one site needs the w's and another doesn't, they'll consistently type www or they won't. Displaying www on www sites and omitting it from others is not going to change this.

It's only a quirk of decisions made while developing the HTTP standard what ends up as part of the URL and what doesn't. Why don't we also include whether it's a GET or POST request in the address bar? Or include the cookie string? "Simplify Everything and Don't Let the User See What's Going On if We Don't Think They Need to Know"? How about SSL issuer name and expiry date in the browser at all times? Maybe because user's don't care about that. They don't care about http or www either. Like the SSL information, the full URL is irrelevant to most users and a click away for those that want to see it.

If firefox was making it difficult to see the complete URL, I'd agree but these arguments seem to be due to a historic attachment to www more than anything practical. This is like complaining about Microsoft removing My from My Documents, My Computer for consistency to users because some icon's had My and some did not.

I guess I'm just for making things consistent. I do wonder how many people would be on the opposite side of the argument entirely if Firefox chose to add www to sites that don't have it rather than remove it from sites that do.

[yoasif]

I guess I'm just for making things consistent. I do wonder how many people would be on the opposite side of the argument entirely if Firefox chose to add www to sites that don't have it rather than remove it from sites that do.

That would be just as bad. What would you expect? People to be in favor of it? To what end?

[TRPB]

That would be just as bad. What would you expect? People to be in favor it? To what end?

No, but a lot of this discussion seems to be down to individual preferences to have www or not rather than general usability concerns.

"My site is not going to be affected by this change and it displays URLs in the way I like therefore I'm all for it"

vs

"My site is going to be affected by this and it displays URLs in a way I don't like therefore I'm against it"

edit: I should note that this was more obvious in the discussion on Hacker News than here.

[CharmCityCrab]

I don't think that's what's happening here. Firstly, padlock icons are displayed so the user can differentiate between HTTP and HTTPS, so that's a non-issue. And in 99.9% (Probably more) of cases www is completely irrelevant because non-www and www domains function identically. Sure, there are some sites that do this but a user will never remember that one site needs the w's and another doesn't, they'll consistently type www or they won't. Displaying www on www sites and omitting it from others is not going to change this.

It's only a quirk of decisions made while developing the HTTP standard what ends up as part of the URL and what doesn't. Why don't we also include whether it's a GET or POST request in the address bar? Or include the cookie string? "Simplify Everything and Don't Let the User See What's Going On if We Don't Think They Need to Know"? How about SSL issuer name and expiry date in the browser at all times? Maybe because user's don't care about that. They don't care about http or www either.

You're trying to be Chrome and you never will be. You can be Firefox, though, which at it's best was a damn fine browser. I read some of this stuff, and doesn't get me mad or upset so much as it just makes me sad. This whole project has lost it's way. Someone with some vision needs to step in here and say "This is demeaning, this project is supposed to be about something.".

Since you have taken the green color off the padlock icon, if you really don't have space for a padlock and the protocol, why not use https:// instead? Make it green if you really feel you must. Include http:// instead of the crossed out padlock and make it red if you really feel you must. Under no circumstances should a browser be dictating what parts of the URL we can and can not see, though (I don't even really like the color coding, but there's a way to make it work for both sides of this debate if that's even something that developers are looking for). That's a Microsoft move, the type of thing that they'd have done at the height of their illegal Internet 5 monopoly, which sadly crushed Netscape, the better product and the company that launched Firefox by open-sourcing it's code. That's a Chrome move, and we all know the point of Chrome, why it was named Chrome ironically after "user-chrome", the part of the interface the user sees, is that Chrome wants to get rid of as much interface as possible, including URLs, and is just doing it slowly like putting a frog in water and turning up the temperature, because in the end Chrome wants you right on the web, relying on the web, not knowing what you're viewing or why you're viewing it, with Google as your handy tour guide, and not being able to customize it, because Google wants to shove it's ads right down your throat and collect every bit of information there is to know about you, including things you don't even know about yourself, but that they can analyze and use to make money off you.

You folks know these things, right? If not, and I am not being sarcastic here, I really do hope this prompts you to learn them. Sometimes people can be brilliant at coding and useability metrics and such, but are fresh out of school and don't know the history of web browsing and who they are working for and why that company is what it is and what it really stands for, or is supposed to stand for. There's no shame in admitting what you don't know and then learning it and applying it. And Mozilla isn't supposed to just be about basic functionality and going with the flow. Go work at Google or Apple or someplace like that if you want that, they love that stuff. Your users are with you because they believe, or want to believe, that Mozilla is different. So, be different.

To answer some of your questions:

Yes, there should be a small box by the URL bar you click on where you view the full SSL certificate, including the issuer, for any https:// site. It's on Firefox for desktop- there are two clicks involved instead of one, and there really should only be one, but it all comes up.

While there literally is not enough room to include GET and POST requests and cookie strings on the URL bar, maybe you should be able to get them by touching below the SSL certificate and issuer after you've touched to get the SSL information, and call them them up that way.

While we're at it, a way to view the source code for websites would be bad either (On desktop for Firefox, you can hold down the control button and the "u" button to get that or go to Tools>Web Developer>Page Source).

The more information you can include, the better.

Look, my phone has 12 gigs of RAM. My PC only has 8 gigs of RAM. The screens are big enough on phones to do a lot more than they used to. Mozilla is supposed to be about user freedom and user information. If someone doesn't want to be bothered with full URLs and have access to all sorts of information, every other browser in the world is for that man or woman. Firefox is supposed to be different, not just more of the same. You guys are turning it into more of the same.

The good news, though, is that you have an opportunity to look at what's going on, think about it, and change your minds. How hard would it be to reverse course on this bug and some of the other stuff people bring up? It could be done. You're getting creamed in the tech press, and rightly so, but you can fix it. Just have the courage to look at yourself in the mirror, say "We were wrong.", fix your mistakes, and do better next time.

[TRPB]

To be clear, I am not a mozilla employee, apologies if I came across that way. I'm a web developer and enthusiastic user who's been using Firefox since it was called Phoenix.

I agree that all that information should be available, but it does not need to be visible all the time.

While there literally is not enough room to include GET and POST requests and cookie strings on the URL bar, maybe you should be able to get them by touching below the SSL certificate and issuer after you've touched to get the SSL information, and call them them up that way.

But this is the same argument. We could remove www and http to make room GET/POST. The HTTP specification could have been written so that URLs were in the format https://GET:www.domain.com/ I'm glad they weren't and the reasons for not doing so are sound, but it's only a quirk of earlier standards what happens to be in the URL in the first place. There's a whole bunch of other stuff that makes up the HTTP request which we don't show to users because it's not meaningful to them.

Why remove the separate stop and reload buttons (by default)? Why remove the bookmarks toolbar (by default)? Why hide the menu bar (by default)? We could keep the old cluttered UI because we want to show everything we can to the user. If this stuff isn't useful for most users and the ones who want it have the ability to enable it or access it via another route, why show it to all users for the few that want it? As long as it remains customisable I don't see the issue with providing a minimalist default.

[opusforlife2]

I'll give a concrete example of what happened to me just yesterday:

I opened a website from a link and used it. Later on, when I entered the URL manually, it gave me a 403 Forbidden error.

What are the steps a user would normally take in such a case? Refresh the page. Close the browser and open the page again. Check online forums to see if the site administrators changed something.

You know what the user wouldn't do? Tap on the address bar or the security lock to see that yes, the full URL indeed contains a www that was omitted by the browser. I only came to know this when I opened the site from a link again later, only to see that that same URL was working now for some reason.

HTTP/HTTPS being replaced by the lock icons isn't that big of a deal to me because it at least provides equivalent information. But from my point of view, that missing www is a regression and a bug, because both desktop Firefox and Fennec would have shown it, and would have saved me the headache I've explained above.