665580 - Hide http:// and single trailing slashes in the location bar

Status: VERIFIED FIXED

(Firefox :: Address Bar, enhancement)

Description

[Dão Gottwald [:dao]]

Attachment: patch

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/[e-mail]-c2d9fef1f3f2

Comment 1

[:Gavin Sharp [email: [e-mail]]]

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?

Comment 2

[Dão Gottwald [:dao]]

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

Comment 3

[Dão Gottwald [:dao]]

Attachment: patch

dropping links on the location bar fixed

Comment 4

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

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 5

[Dão Gottwald [:dao]]

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 6

[Shawn Wilsher :sdwilsh]

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.

Comment 7

[:Gavin Sharp [email: [e-mail]]]

please no javadoc - it makes my eyes bleed

Comment 8

[(mostly gone) XtC4UaLL [:xtc4uall]]

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.

Comment 9

[Jonathan Jacobs]

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.

Comment 10

[Dão Gottwald [:dao]]

http://hg.mozilla.org/mozilla-central/rev/2af378ef814c

Comment 11

[Dão Gottwald [:dao]]

(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.

Comment 12

[Ekanan Ketunuti]

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).

Comment 13

[Dão Gottwald [:dao]]

(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.

Comment 14

[Daniel C]

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 15

[:Gavin Sharp [email: [e-mail]]]

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.

Comment 16

[Dão Gottwald [:dao]]

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

Comment 17

[Dão Gottwald [:dao]]

> 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

Comment 18

[:Gavin Sharp [email: [e-mail]]]

(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).

Comment 19

[MrX1980]

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

Comment 20

[tonda kavalec]

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.

Comment 21

[Jean-Yves Perrier [:teoli]]

> 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.

Comment 22

[Roberto Bouzout (tito)]

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?

Comment 23

[tonda kavalec]

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".

Comment 24

[Josh Triplett]

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.

Comment 25

[Artem S. Tashkinov]

(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.

Comment 26

[Vlad [QA]]

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

Comment 27

[Travis Smith]

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.

Comment 28

[Odbayar Nyamtseren]

Why not just grey it out like on IE8?

Comment 29

[tonda kavalec]

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

Comment 30

[tonda kavalec]

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

Comment 31

[hikaricore]

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..

Comment 32

[hikaricore]

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

Comment 33

[Atul Varma [:atul]]

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.

Comment 34

[tonda kavalec]

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.

Comment 35

[Olli Pettay [:smaug][[e-mail]]]

(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?

Comment 36

[Jan Bassez]

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.

Comment 37

[Jan Bassez]

(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

Comment 38

[Shawn Wilsher :sdwilsh]

(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.

Comment 39

[tonda kavalec]

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

Comment 40

[:Gavin Sharp [email: [e-mail]]]

(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.

Comment 41

[tonda kavalec]

You started the discussion, not me. Your "argument" is just ****.

Read the comments above!

Comment 42

[Jan Bassez]

(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?

Comment 43

[Jan Bassez]

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.

Comment 44

[Olli Pettay [:smaug][[e-mail]]]

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

Comment 45

[Petr Cerny [:hrosik]]

(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).

Comment 46

[Daniel Jensen]

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?

Comment 47

[:Gavin Sharp [email: [e-mail]]]

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.

Comment 49

[Marcelo Garbarino]

(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.

Comment 50

[Martin Jungowski]

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!

Comment 51

[Thorin]

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.

Comment 52

[Jan Bassez]

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.

Comment 53

[Raptor007]

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.

Comment 54

[Jerry Baker]

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.

Comment 55

[John]

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.)

Comment 56

[Jan Bassez]

@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...

Comment 57

[Jerry Baker]

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?

Comment 58

[VikeSinha]

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.

Comment 59

[:Gavin Sharp [email: [e-mail]]]

(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.

Comment 60

[VikeSinha]

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

Comment 61

[iccor56]

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

Comment 62

[Magnus Melin [:mkmelin]]

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

Comment 64

[posita]

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

Comment 65

[nemo]

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.

Comment 66

[nemo]

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..