This makes the location bar more user-friendly, Chrome and Opera are already doing it. Can we follow their lead? Try builds will appear here when they are ready: http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/dgottwald@mozilla.com-c2d9fef1f3f2

Comment on attachment 540497 [details] [diff] [review] patch >diff --git a/browser/base/content/urlbarBindings.xml b/browser/base/content/urlbarBindings.xml >- try { >- uri = makeURI(val); >- } catch (e) {} >+ let uri = gBrowser.currentURI; Won't this produce incorrect results when you're copying an edited URL?

This doesn't handle edited URLs due to the this.getAttribute("pageproxystate") == "valid" check.

dropping links on the location bar fixed

Comment on attachment 540817 [details] [diff] [review] patch go ahead and land this on the UX branch first. We'll want to check it in on nightly along with a larger set of changes, so that we don't trigger debates until we haven everything perfect. We can discuss all the details at the Firefox work week coming up.

Comment on attachment 540817 [details] [diff] [review] patch Shawn, do you want to review this? If you're available, please cancel the other review request.

Comment on attachment 540817 [details] [diff] [review] patch Review of attachment 540817 [details] [diff] [review]: ----------------------------------------------------------------- Can you add a test for the case that gavin mentioned in comment 1 please? r=sdwilsh ::: browser/base/content/utilityOverlay.js @@ +617,5 @@ > var helpTopic = document.getElementsByTagName("prefwindow")[0].currentPane.helpTopic; > openHelpLink(helpTopic, !instantApply); > } > + > +function trimURL(aURL) { Could you please add java-doc style comments on this method explaining what it does? I'd hate to have to read this regular expression every time I wanted to figure out what it was doing.

please no javadoc - it makes my eyes bleed

Dão, did you land this on http://hg.mozilla.org/mozilla-central/rev/2af378ef814c pref'ed on on Purpose? Just wondering cause of Comment 4.

It would be really useful if the copy behaviour matched Chrome too: If the first character is included in the copy selection then prepend the protocol.

(In reply to comment #8) > Dão, did you land this on > http://hg.mozilla.org/mozilla-central/rev/2af378ef814c pref'ed on on > Purpose? Just wondering cause of Comment 4. Yes, this doesn't depend on other changes, afaik, and I don't want this to hide in a batch of other controversial changes. This should be able to stand on its own, for better or worse. (In reply to comment #9) > It would be really useful if the copy behaviour matched Chrome too: If the > first character is included in the copy selection then prepend the protocol. Feel free to file a bug on this.

won't merge back to UX? I see some code from m-c (http://hg.mozilla.org/mozilla-central/rev/2af378ef814c) are differ from UX (https://hg.mozilla.org/projects/ux/rev/8bad8093f5d9).

(In reply to comment #12) > won't merge back to UX? I see some code from m-c > (http://hg.mozilla.org/mozilla-central/rev/2af378ef814c) are differ from UX > (https://hg.mozilla.org/projects/ux/rev/8bad8093f5d9). I backed this out from ux in order to avoid merge conflicts.

function testVal(originalValue, tragetValue Should be targetValue. Also, I think browser/base/content/test/browser_urlbarTrimURLs.js and browser/base/content/test/browser_urlHighlight.js should have tests for view-source: URLs because they don't match the pattern: let protocol = value.match(/^[a-z]+:/);

Comment on attachment 540817 [details] [diff] [review] patch >diff --git a/browser/base/content/test/browser_urlbarTrimURLs.js b/browser/base/content/test/browser_urlbarTrimURLs.js This test should have a license header. >diff --git a/browser/base/content/urlbarBindings.xml b/browser/base/content/urlbarBindings.xml > this.value = url; > SetPageProxyState("invalid"); > this.focus(); > try { >- urlSecurityCheck(this.value, >+ urlSecurityCheck(url, > gBrowser.contentPrincipal, > Ci.nsIScriptSecurityManager.DISALLOW_INHERIT_PRINCIPAL); > } catch (ex) { > return; > } > this.handleCommand(); Why did you make this change? handleCommand loads this.value.

urlSecurityCheck can't deal with this.value lacking http://, handleCommand can.

> Also, I think browser/base/content/test/browser_urlbarTrimURLs.js and > browser/base/content/test/browser_urlHighlight.js should have tests for > view-source: URLs because they don't match the pattern: let protocol = > value.match(/^[a-z]+:/); filed bug 666717 on this

(In reply to comment #2) > This doesn't handle edited URLs due to the > this.getAttribute("pageproxystate") == "valid" check. The .value setter does not affect pageproxystate, so there's still a risk that the URL bar value won't actually match the currentURI (though probably not without some weird extension involvement, granted).

For all users who don't need/like it: about:config -> browser.urlbar.trimURLs = false

You don't have to make every ****, which other do ... The arguments are ****: "This makes the location bar more user-friendly, Chrome and Opera are already doing it" There is nothing user-friendly on it. Don't you want to remove the addressbar at all? It may distract user :O By Opera the protocol appears after you have clicked in the addressbar.

> By Opera the protocol appears after you have clicked in the addressbar. I've filled Bug 667271 for the interesting part of your comment, so that devs would consider if it is a good idea or not.

I don't know from where you decide what is "user friendly" and what is not. Yesterday I "installed" a laptop for a friend parent, and they refused to use Firefox because the menu-bar was not visible by default. I just installed Firefox and removed any reference to Internet Explorer. To learn from they behavior, I was just sit there without providing any information on how to use it. After watching a while (15 minutes), they wanted Internet Explorer back at any cost. They were unable to understand the "Firefox button" (was this button named "user friendly"?) and they were unable to understand how to set the menu-bar again. (also it was a little difficult to me to enable the menu-bar since many right-clicks was not showing "Menu Bar" option) Instead of constantly removing "things" from the browser, why don't work on the many thing that are broken?

Well the UI of IE is terrible, enabling menu in Firefox = 2s But I agree with you, a lot of people uses the term "user-friendly" as en argument they can use whenever they need some "argument".

Hiding the http:// seems fine to me; it seems unambiguous, since the lack of a scheme can always indicate http and nothing else. However, hiding a trailing slash actually changes the URL; /foo and /foo/ can refer to different pages, and sometimes it matters to know which one refers to the current page. Furthermore, hiding the trailing slash seems to have very little benefit compared to hiding the scheme.

(In reply to comment #24) If I'm not mistaken a trailing slash is only removed when you're on the root page of a site.

Setting resolution to Verified Fixed on Mozilla/5.0 (Windows NT 6.1; rv:7.0a1) Gecko/20110626 Firefox/7.0a1

As someone who has fought with the Chromium dev team over this very same change, I want to say *thank you* for providing the option to restore the full URI in about:config. That said, I do not agree with the reason for the change. By hiding the scheme for http only you are introducing an inconsistent behavior, training users to exclude the scheme when they share web addresses, and by extension, breaking parsers everywhere which are expecting valid URI syntax. To quote RFC 3986 for URIs, "The scheme and path components are required". I understand the removal of the scheme on mobile browsers where 7 characters takes up a good portion of the screen. On a desktop browser, that is unlikely if ever the case. If the scheme is considered too confusing for regular users, why is http the only one being stripped out? What will new users think when they see "https://" or "ftp://" for the first time? As long as the option to restore the full URI remains, I can live with the change, however I do not agree that it makes the browser more "user-friendly". In fact, I believe it will do the exact opposite.

Why not just grey it out like on IE8?

it is not necessary to do anything, that's the problem

sure, only bring back the old behavior without hiding anything .......

More absurd and unneeded changes... Now that you've gone and ""fixed"" this would you mind telling us how to fix it to work the way it should still in the first place? Right now I use a couple addons to restore functionality which actually belongs in the browser. If this keeps up I'll have a dozen more by the end of the year..

Nevermind I overlooked the browser.urlbar.trimURLs comment. Still a needless change though.

Just wanted to chime in and say that I agree with Travis Smith in Comment 27, with respect to the behavior being inconsistent. Trying to abstract away protocol information under some easier-to-understand concept is one thing, but selectively hiding only one protocol and keeping the others makes things *more* complex, not less. If I had to teach someone how to use a browser from scratch, I can guarantee you I'd have a harder time doing it with this patch landed. Furthermore, the copy/paste behavior used by Chrome and proposed in bug 666964 breaks copy/paste expectations in two ways: * When someone copies text, they expect it to be the *exact same* text when they paste it. Just as I wouldn't expect copying the text "hi there" to be pasted as "LOL hi there", I also wouldn't expect copying "www.google.com" to be pasted as "http://www.google.com/". * In Chrome, the content of the copy is actually modal. Try typing a search term into the omnibar, press the "down" arrow to find a http-less URL that you need, select the contents of the address bar, and copy the text to the clipboard. The pasted text is also http-less. However, repeat the process, but press "enter" before selecting the address bar's contents. This will make the browser navigate to the URL. Note that there is *no change* in the contents of the address bar, yet now selecting said contents, copying and pasting will result in a URL with http:// at the beginning. I fail to see how any of this makes an interface easier to use. If we really want to hide protocol information and free up more screen space, I'd rather see the UX mobile safari uses, whereby the protocol information for any kind of URL is still in the address bar, but just slides out of view when the address bar isn't focused.

This is what does Opera, but you don't save any space, even in Opera happens the opposite, sorry for my language, but the idea is just ****, nothing more. If I am not wrong, having only IE8, being on XP, even IE does not hide the protocol (In reply to comment #33) , I'd rather see the UX mobile safari uses, whereby the protocol > information for any kind of URL is still in the address bar, but just slides > out of view when the address bar isn't focused.

(In reply to comment #27) > That said, I do not agree with the reason for the change. By hiding the > scheme for http only you are introducing an inconsistent behavior, training > users to exclude the scheme when they share web addresses I fully agree with this. The current inconsistency is terrible. This breaks sane copy-paste behavior (since either I can't copy the whole URL, or I can't see what is copied), and I have no idea which protocol is used. If I just forget which all protocols are hidden, I could assume that also https is hidden. Has anyone done any user studies about this change?

hey yea, came to report a bug but saw this first -> when I copy from the address bar, http:// isn't copied, but as this is required by some websites to create a link (for instance discogs.com) this creates false (non-working) links which have to be corrected.

(In reply to comment #36) > hey yea, came to report a bug but saw this first -> when I copy from the > address bar, http:// isn't copied, but as this is required by some websites > to create a link (for instance discogs.com) this creates false (non-working) > links which have to be corrected. oh yes, want to add: this can be solved by making to re-appear the http:// (or whatever is there) when selecting the address-bar

(In reply to comment #27) > To quote RFC 3986 for URIs, "The scheme and path components are required". It's a location bar, not a URI bar.

Stop playing with words, location without protocol, does not specify any location. It really does not matter how it is called, but it matters, what it is. It is also called address-bar. "Location bar" is a terminus technicus, it does not contain only the location / url / address

(In reply to comment #39) > location without protocol, does not specify any location. Perhaps that's true to you, but it isn't true to the majority of the Web-using public. Adding "http://" in front of "www.google.com" does not usefully disambiguate it in practice. Please, let's stop discussing this here. If you feel compelled to advocate for different UI behaviors, the newsgroups are the appropriate forum.

You started the discussion, not me. Your "argument" is just ****. Read the comments above!

(In reply to comment #40) > (In reply to comment #39) > > location without protocol, does not specify any location. > > Perhaps that's true to you, but it isn't true to the majority of the > Web-using public. Adding "http://" in front of "www.google.com" does not > usefully disambiguate it in practice. > > Please, let's stop discussing this here. If you feel compelled to advocate > for different UI behaviors, the newsgroups are the appropriate forum. huh??? The majority of users doesn't realise the importance of that protocol prefix... And hiding it will even make that worse, spoiling the web with links without protocol. BAD Idea... I don't know any user in the world that expressed having problems with the http:// or https:// or ftp:// or ... prefixes that are added to a web address. Hiding those is a bad idea and only makes things more complicated. There is no single advantage in doing so, there are numerous disadvantages. It doesn't make a browser more user-friendly in any way, only the opposite. The only thing it does is creating annoyances and extra clutter-code to make things al-right back again. And I don't use Firefox because I like Chrome, Opera or IE better. Running behind what does browsers do isn't a good idea, especially counts for Chrome and IE. Let those be different. Chrome even uses the address bar, or location bar (or how you want to call it) as a search box. I know people who like Chrome a lot because of that. I know other people, including myself, how think that's a reason NOT to use Chrome. Same with the hiding. Firefox is the browser of choice for a lot more advanced web users, where Chrome and IE focus purely on mindless mass-consuming users who don't have an idea, and don't want to have an idea what they're actually doing. The sole argument brought forward to hide the protocol in the URL was 'Opera and Chrome' also do this. Are we Lemmings™ or what?

Oh yes, want to add: if this is something that can be turned off/on by a setting, things would be different. Preferably with a standard keyboard shortcut, or small button near the address/location-bar, or accessible with a right click on that bar. So that it can be turned off (or on) anywhere, anytime when one wishes to.

about:config browser.urlbar.trimURLs=false gives back consistent and sane UI.

(In reply to comment #44) > browser.urlbar.trimURLs=false > gives back consistent and sane UI. This should probably be the default. It wouldn't confuse users (and introduce inconsistency just because someone else does so), unless they ask for it (and by then they should be knowing what they are doing).

I completely agree with Atul. This change: *breaks compliance with at least 2 important RFCs (so much for standards) *introduces bugs and complications esp with copy-paste *breaks user expectations about the copying and pasting of plain text *makes the security situation (http vs https) even more confusing for users *treats http as the favored default when people should be going https everywhere *has no proven ux benefits (no studies, no testing, no data, not even a survey) It was a bad idea when Chrome did it and it's still a bad idea now. Should we treat bug 667178 as the "back this mistake out please" bug?

None of the relevant RFCs apply to user interfaces. The vast majority of users have a concept of URLs that have absolutely nothing to do with RFCs, so citing that as an argument against this change is unproductive. The bugs related to copy/paste inconsistencies need to be fixed, absolutely. We're tracking those separately, and some of them have already been fixed. This change doesn't favor one type of connection over another - "http://" was the default protocol for unprefixed URIs entered into the location bar since the beginning of time, and this bug didn't change that. Advocacy in Bugzilla has a very high cost/reward ratio, particularly on a bug that has this many people watching.

(In reply to Petr Cerny [:hrosik] from comment #45) > This should probably be the default. It wouldn't confuse users (and > introduce inconsistency just because someone else does so), unless they ask > for it (and by then they should be knowing what they are doing). I completely agree! I have to thank, anyway, the Mozilla team for giving us the option to turn this bug off.

How about, while you're at it, you also hide the TLD? I mean come on, why should users even care whether they're on facebook.com or facebook.co.uk or facebook.de or facebook.net? That's just confusing! Actually, you can also hide the domain, after all users can *SEE* what website they're on so they don't need the location bar. That's just confusing! I'm sorry but this is just plain stupid. Infact, it's the most stupid thing Mozilla has ever done. And why? Because, and I quote, "Chrome and Opera are already doing it". Awesome!

I'm with comments 46, 49, and 50. This change is horrible. The setting should be in the Options dialog not buried in about:config and the default should be to display the protocol section as it was previously. If people wanted Opera or Chrome like functionality would they be using Firefox? Following the other lemmings off the hill is NOT a good justification for implementing a change/feature.

Agree completely. Firefox is not a lemming behind Opera, and for sure not behind that Chrome wreck. Default behaviour should be: What-you-see-is-what-you-get. The hype of minimalism is no more than a mere short-living rage that will be over soon because of all inconvenience it creates to the majority of users. It breaks normal OS behavior, I have never seen a situation where ctrl-c doesn't copy what you see, but if it copies what it sees, you create lots of wrong links if you don't correct them manually. I really don't understand this ill behavior was allowed to enter a browser which has always been outstanding in it's solid behavior, as opposed to Internet Explorer & Chrome for instance.

I'm actually happy with the new behavior, but why doesn't it apply to https as well? The favicon section already expands to show the certificate domain, so that should be enough visual indication of an https connection. I agree that this toggle should be somewhere in the Preferences, so people who don't want trimmed URLs can change the setting more easily.

Is a bug supposed to be marked as resolved when there are open dependencies? https://bugzilla.mozilla.org/page.cgi?id=fields.html#dependson seems to suggest not.

Thanks for leaving the option to turn this off. Along with the other problems this causes, here is another scenario it screws up: 1. I type qa in the bar 2. http://qa.example.com/ is shown first in the match box 3. I hit the down arrow, bringing that value up to save some typing 4. I type 'f' expecting it to further match to http://qa.example.com/foo/bar/page.html This worked in the past, but stopped working when this change went in. At first I couldn't figure out what was going wrong - I kept not matching sites. Well, it's because this dumb change strips the '/' off the URL when you select it from the list. Just typing the 'f' resulted in it looking for qa.example.comf. With this change I am forced to type '/' then 'f' in order to properly match my destination. I have a lot of muscle memory/procedural inertia with Firefox since I use it so much during the day developing web sites. Changes like this that screw that up and bring nothing to the table in return are irritating. (Another example - swapping open in new tab and open in new window in the menus. Now I have to move my mouse a different amount than I have for the past 5 years, and for what reason? Changes need to have some good benefit to the user.)

@John: I'm not sure, but I think your problem should be submitted as a separate bug, if not present here already. I agree with you that is is a shame to see a good browser going downhill following short-lived fashions from other browers, who either perform far less (Chrome), or either have a different focus (Opera). I'm not thankful at all that I need to turn of that option through about:config I'm testing nightly with custom settings right now, I should be testing it with default settings so I know what possible mess should be worked away. They could provide an option to turn the hiding on, if they think people are bothered by seeing the internet protocol used. The good thing is such decissions are mostly short-lived things which dissappear by themselves after a while. It's just those guys who already put so much effort in this 'thing' who need to be ready to bury the idea. Every good creator (be it programmer, artist, architect, or whatever) needs to learn to 'kill his darlings' from time to time. Some ideas which are good on their own (as isolated idea) spoil the big idea. That's when one needs to kill his darlings, even after a lot of effort. (To avoid putting more effort in it) Here it's ok, they can still provide it as an option later, so their effort hasn't been completely useless...

Is the improvement in functionality from hiding 7 characters from users so substantial and important that 14 regressions and the associated resources to address them are justified?

Not sure if someone's mentioned this yet, but on a Mac, using Cmd+Enter to complete addresses is now broken for sites with sub-domains (eg. store.apple.com). I have a feeling this 'feature' brought about the problem and would appreciate someone with the know-how look into it to resolve the issue which was brought up by a useless feature in the first place... Also, my two cents about hiding the prefix: It's not unequivocally bad, but as mentioned in comment 53; if it's gonna be like this then it should at least be consistent and apply to "https://" as well, because the favicon already makes it abundantly clear when you're on a secure site. Come on Firefox, get your **** together. This has always been a super-solid browser and my first choice, let alone the first choice of every discerning internet user I know. Conformity with competitors is a lousy justification for functionality change, especially if it's supposed to stand alone as the only supporting argument in favor of it.

(In reply to VikeSinha from comment #58) > Not sure if someone's mentioned this yet, but on a Mac, using Cmd+Enter to > complete addresses is now broken for sites with sub-domains (eg. > store.apple.com). I can't reproduce this. Could you file a separate bug for this, CC me, and provide more detailed steps to reproduce? I'd be happy to look into it.

Done. But this has been my first bug filed so just in case I've done it wrong, it's here: https://bugzilla.mozilla.org/show_bug.cgi?id=701991

as this is a feature not a bug as stated above is there a way to disable this feature and show the protocol used?

Yes: browser.urlbar.trimURLs false, see comment 19.

I realize this is "fixed", but for tracking purposes, this is the backlash Google has received from breaking RFC 3986 with their URL bar magic: http://code.google.com/p/chromium/issues/detail?id=41467 (now closed to additional hate mail) http://code.google.com/p/chromium/issues/detail?id=131143

Heh. WRT comment #65 - well deserved if it is anything like Firefox' implementation. Disabling trimURLs is the first thing I do when setting up a new profile. Unfortunately this default still causes broken URLs for me a couple of times a day in test profiles, as I select part of a link then middle click to paste, or delete a few characters from the end, then select the rest and middle click to paste, or even when using ctrl-c/ctrl-v in some obscure situations. And yes, this happens in Firefox 17 still, since I'm usually testing the nightly. Not to mention hiding http in general encourages users to enter URLs without the http:// which screws up autolinking. Then there are the ones who I have to explain who are confused and think that https:// indicates a different website, now, since they got used to no http://. Horrible feature :-/ I was actually surprised Firefox hasn't received as much hate on this as Chrome did in the bugs you linked to. There *is* bug #722670, bug #781588 (broken stuff due to trimURL) and bug #667271 (+2 duplicates) for the Opera functionality, and the odd bug like bug #670089 hating on it in general. But overall, pretty quiet. I mean. I've encountered plenty of people confused by it at work and play, but no one appears to be complaining on bugzilla.

FWIW, found two more situations where hiding http:// is broken. I'd ctrl-clicked on a slow site to open in a new tab, and while the site was loading, doubleclicked on the url bar to select. This copied the url bar to the X paste buffer, which I then pasted into a tab. http:// was missing. In addition, if I turn off trimUrls, and select an entry from history in the awesomebar, http:// does not appear until the site has loaded, regardless of what the history entry was. Eh, One more plea for the opera implementation..