Turn back on a protocol name in the address bar

[Artem Mikhmel]

Turn back on a protocol name in the address bar, please!

[John Munro]

I wouldn't go so far as to demand the protocol be added back to the
omnibar, I'm just curious as to the reasons why.

Personally I prefer to see the protocol there, and I think it's more
consistent to see http/https rather than nothing/https, but I can
understand that less technical users don't know what http means.

[Marc Qualie]

I agree with John on how less technical users don't know what it
means, but I think it somehow looks "bare" without the http://
Maybe it should be off by default (for general users) and an option
inside under the hood or something to turn it on for others?
Also http has been around long enough in other browsers for people to
recognise it.
Also copy/paste into instant messengers/site to share links isn't as
easy as alot of links won't highlight/detect automatically as they
would with http:// prefix
Just a small inconvenience, but just my opinion.

[Artem Mikhmel]

The one simple reason for it is:
when you just select a part of URL in the address bar and copy it into
a buffer, only selected part with no protocol name is copied.
Why this usability experiments, thinking users are idiots and affraid
of protocol name?

Ok, if you think so, just make an option for non-idiots to show a full
URI in address bar.

[Caleb Eggensperger]

I, for one, much prefer not having the protocol -- it makes the address bar easier to read at a glance and it removes extraneous information.

--
Chromium Discussion mailing list: chromium...@chromium.org
View archives, change email options, or unsubscribe:
   http://groups.google.com/a/chromium.org/group/chromium-discuss

--
Caleb Eggensperger
http://calebegg.com/

[Alexander Skwar]

I'd like to have the protocol information. Or, actually,

I wouldn't mind to NOT see the address at all normally.

It should be easily accessible (via a keyboard shortcut

and/or some button), but usually, I couldn't care less.

BUT: If the adress is shown, please show the COMPLETE

address. This INCLUDES the protocol!

2010/4/13 Caleb Eggensperger <cale...@gmail.com>

--
Alexander
--
↯    Lifestream (Twitter, Blog, …) ↣ http://alexs77.soup.io/     ↯
↯ Chat (Jabber/Google Talk) ↣ a.s...@gmail.com , AIM: alexws77  ↯

[Portman]

Can someone from the Chromium team please give a canonical reason why
the http:// (but not https://) was removed?

The only mention of this is in Issue 40865, but the developer
explicitly asked users to NOT comment on that issue.
http://code.google.com/p/chromium/issues/detail?id=40865

I think y'all are setting yourselves up for a big backlash/fail when
this gets promoted to the stable channel. It would be prudent to open
up discussion and feedback just a little before making such a big
change.

On Apr 13, 2:06 pm, Alexander Skwar <a.sk...@gmail.com> wrote:
> I'd like to have the protocol information. Or, actually,
> I wouldn't mind to NOT see the address at all normally.
> It should be easily accessible (via a keyboard shortcut
> and/or some button), but usually, I couldn't care less.
>
> BUT: If the adress is shown, please show the COMPLETE
> address. This INCLUDES the protocol!
>

> 2010/4/13 Caleb Eggensperger <caleb...@gmail.com>

>
>
>
>
>
> > I, for one, much prefer not having the protocol -- it makes the address bar
> > easier to read at a glance and it removes extraneous information.
>

> > On Tue, Apr 13, 2010 at 09:48, Artem Mikhmel <amikh...@gmail.com> wrote:
>
> >> The one simple reason for it is:
> >> when you just select a part of URL in the address bar and copy it into
> >> a buffer, only selected part with no protocol name is copied.
> >> Why this usability experiments, thinking users are idiots and affraid
> >> of protocol name?
>
> >> Ok, if you think so, just make an option for non-idiots to show a full
> >> URI in address bar.
>
> >> On 13 апр, 16:41, John Munro <ghost...@gmail.com> wrote:
> >> > I wouldn't go so far as to demand the protocol be added back to the
> >> > omnibar, I'm just curious as to the reasons why.
>
> >> > Personally I prefer to see the protocol there, and I think it's more
> >> > consistent to see http/https rather than nothing/https, but I can
> >> > understand that less technical users don't know what http means.
>
> >> > On Apr 13, 2:05 am, Artem Mikhmel <amikh...@gmail.com> wrote:
>
> >> > > Turn back on a protocol name in the address bar, please!
>
> >> --

> >> Chromium Discussion mailing list: chromium-disc...@chromium.org

> >> View archives, change email options, or unsubscribe:
> >>    http://groups.google.com/a/chromium.org/group/chromium-discuss
>
> > --
> > Caleb Eggensperger
> >http://calebegg.com/
>
> >  --

> > Chromium Discussion mailing list: chromium-disc...@chromium.org

> > View archives, change email options, or unsubscribe:
> >http://groups.google.com/a/chromium.org/group/chromium-discuss
>
> --
> Alexander
> --
> ↯    Lifestream (Twitter, Blog, …) ↣http://alexs77.soup.io/    ↯

> ↯ Chat (Jabber/Google Talk) ↣ a.sk...@gmail.com , AIM: alexws77  ↯

[Simon B.]

Maybe its time to fork the Chromium project, or at least get a more
independent distribution running (SRWare Iron doesn't seem independent
enought for my tastes).

Comment 29 by pkas...@chromium.org, Today (67 minutes ago)
>NOT ABOUT REMOVING "HTTP". DON'T POST ABOUT THAT.

Also, pkasting, please, before TALKING LOUD to ppl who support and
love your project, get your own house in order.

Obviously d...@chromium.org is merging lots of bugs where the
discussion could have gone. Make sure to have a bug/feature request
where ppl can demand getting http(s):// back and STOP merging those
into the place where you don't want discussion.

Another good idea would be to move all mentions of "http://" and
related merges into their appropriate feature request, so we can all
go to star there and conspire on how to get the protocol back.

Example:

Comment 9 by d...@chromium.org, Yesterday (37 hours ago)
Issue 41146 has been merged into this issue.
lost http from omnibar
d...@chromium.org, Yesterday (38 hours ago) This is part not
a bug, but part of the M5 Omnibox updates.

[Graham Triggs]

It's very simple. It could be optional to display the protocol. It
could [also] be optional to display the protocol in a fainter colour
(ie. medium grey).

Both of these would allow you to glance at the address bar with fewer
distractions.

But to simply force removing the protocol on everyone is not the way
to go - it's seriously inconveniencing a good number of people (myself
included).

[Andrew Benton]

i'm not understanding how it is an inconvenience. Copying to the
clipboard isn't an issue since the http:// is prepended in that case.
what other inconveniences are there?

[Graham Triggs]

Because that simply isn't true in all cases.

Sometimes it will paste in the protocol. Many other cases -
particularly when writing rich text emails or wiki pages, it pastes in
the text without the http:// prepended, but with the text linked.

But you definitely don't want the text to appear without the http://
in those circumstances, and you can't really just type it at the start
- you have to highlight / use the link buttons, etc.

If it guaranteed that the text was pasted with the http:// prepended
in ALL circumstances, that would at least be a step forward, and
remove the serious inconvenience.

However, I would still rather have the protocol displayed in the
address bar.

On Apr 14, 7:26 pm, Andrew Benton <andrewmben...@gmail.com> wrote:
> i'm not understanding how it is an inconvenience. Copying to the
> clipboard isn't an issue since the http:// is prepended in that case.
> what other inconveniences are there?
>
>
>
> On Wed, Apr 14, 2010 at 11:20 AM, Graham Triggs <grahamtri...@gmail.com> wrote:
>
> > It's very simple. It could be optional to display the protocol. It
> > could [also] be optional to display the protocol in a fainter colour
> > (ie. medium grey).
>
> > Both of these would allow you to glance at the address bar with fewer
> > distractions.
>
> > But to simply force removing the protocol on everyone is not the way
> > to go - it's seriously inconveniencing a good number of people (myself
> > included).
>
> > On Apr 13, 5:58 pm, Caleb Eggensperger <caleb...@gmail.com> wrote:
> >> I, for one, much prefer not having the protocol -- it makes the address bar
> >> easier to read at a glance and it removes extraneous information.
>
> > --

> > Chromium Discussion mailing list: chromium-disc...@chromium.org

[dhw]

The rich text pasting problems are definitely bugs. You can add a
STAR to the following issues to be notified of updates:

http://code.google.com/p/chromium/issues/detail?id=41173
http://code.google.com/p/chromium/issues/detail?id=41489
http://code.google.com/p/chromium/issues/detail?id=41493

[Artem Mikhmel]

Sure, if you don't understand, nobody shouldn't.

[Ben]

You mean, "nobody should"?

Nobody shouldn't means nobody should not, or everybody should. Whereas nobody should means everybody should not. I love to hate double negatives, even worse when there are more than two. :(

[Andrew Benton]

no need to get hostile. i actually am interested in various ways that
removing http:// might be an annoyance, and so far i have one
excellent answer and a pointer to a few bugs that should alleviate
that particular annoyance. i'm wondering if there are others...

[Artem Mikhmel]

You got what I mean ;)

of cause 'nobody should'

[Alexander Skwar]

It's quite easy to understand why it's an annoyance - because

copy-pasting the URL doesn't work anymore. The http is missing.

At least on Linux.

Here's how:

- In the Omnibox, highlight the address that's shown (eg. useragentstring.com/

when you go to http://useragentstring.com/)

- In some other window (eg. Gnome terminal) push middle mousebutton.

Result: useragentstring.com/ is pasted (which is "correct", since that was,

what was highlighted)

Now, thinking about it, I also do NOT oppose that http:// is hidden 

normally. But as soon as the Omnibox/Addressbar has the focus,

http:// should be shown again, IMO.

And, frankly, I don't get why somebody thought that there's a need

to hide http:// in the first place. Stupid idea. On space limited devices

like mobile phones, it makes sense (that's why Mobile Safari on iPhone

is correct in doing so).

Alexander

2010/4/15 Andrew Benton <andrew...@gmail.com>

--

Alexander
--
↯    Lifestream (Twitter, Blog, …) ↣ http://alexs77.soup.io/     ↯

↯ Chat (Jabber/Google Talk) ↣ a.s...@gmail.com , AIM: alexws77  ↯

[PhistucK]

I think this is a nice solution - when you focus on the Omnibar, show the http. Though that might be jumpy (if you want to focus on an exact letter in the address)... back to the designing table. ;)

☆PhistucK

[Alexander Skwar]

You know, to make it "unjumpy", simply don't hide the http:// in the

first place.

Do you understand what problem they tried to solve by hiding http://?

Oh, here's another problem!

I sometimes have to go to http://ftp.ugs.com/. As it is now, Ctrl+L →

Ctrl+A → Ctrl+c → Ctrl+v will copy:

ftp.ugs.com/

That is, *NO* http:// in front of it!

Oh, it's a general breakage reg. web servers which have a

ftp. as the first part of the name. Example:

http://ftp.mozilla.org/pub/mozilla.org/

Go to that site. Chrome will show: ftp.mozilla.org/pub/mozilla.org/

Focus omnibox (eg. hit ctrl+l) and hit enter (to reload the page).

Result: you're now on the FTP ("ftp://") server. (Visible by how

the icons look like now.)

Oh, whatever happened to the KISS priniciple...? :((

That change was so enormously stupid. Would be good, if Chrome

folks would be brave enough to back out that change again :((

Filed http://crbug.com/41585 and http://crbug.com/41586

2010/4/15 PhistucK <phis...@gmail.com>

[Philip Kahn]

Keep it civilized.

There are bug reports on the handling of copy/pasting. It is known.
Chill. You're on dev.

It behaves properly on plaintext and richtext.

I for one like the new handling. Keeps things cleaner, barring the
minor bugs.

On Apr 15, 12:44 am, Alexander Skwar <a.sk...@gmail.com> wrote:
> You know, to make it "unjumpy", simply don't hide the http:// in the
> first place.
>
> Do you understand what problem they tried to solve by hiding http://?
>
> Oh, here's another problem!
>

> I sometimes have to go tohttp://ftp.ugs.com/. As it is now, Ctrl+L →

> Ctrl+A → Ctrl+c → Ctrl+v will copy:
>
> ftp.ugs.com/
>
> That is, *NO* http:// in front of it!
>
> Oh, it's a general breakage reg. web servers which have a
> ftp. as the first part of the name. Example:
>
> http://ftp.mozilla.org/pub/mozilla.org/
>
> Go to that site. Chrome will show: ftp.mozilla.org/pub/mozilla.org/
> Focus omnibox (eg. hit ctrl+l) and hit enter (to reload the page).
> Result: you're now on the FTP ("ftp://") server. (Visible by how
> the icons look like now.)
>
> Oh, whatever happened to the KISS priniciple...? :((
>
> That change was so enormously stupid. Would be good, if Chrome
> folks would be brave enough to back out that change again :((
>
> Filedhttp://crbug.com/41585andhttp://crbug.com/41586
>

> 2010/4/15 PhistucK <phist...@gmail.com>

>
>
>
>
>
> > I think this is a nice solution - when you focus on the Omnibar, show the
> > http. Though that might be jumpy (if you want to focus on an exact letter in
> > the address)... back to the designing table. ;)
>
> > ☆PhistucK
>

> > On Thu, Apr 15, 2010 at 10:21, Alexander Skwar <a.sk...@gmail.com> wrote:
>
> >> It's quite easy to understand why it's an annoyance - because
> >> copy-pasting the URL doesn't work anymore. The http is missing.
>
> >> At least on Linux.
>
> >> Here's how:
> >> - In the Omnibox, highlight the address that's shown (eg.
> >> useragentstring.com/

> >> when you go tohttp://useragentstring.com/)

> >> - In some other window (eg. Gnome terminal) push middle mousebutton.
> >> Result: useragentstring.com/ is pasted (which is "correct", since that
> >> was,
> >>  what was highlighted)
>
> >> Now, thinking about it, I also do NOT oppose that http:// is hidden
> >> normally. But as soon as the Omnibox/Addressbar has the focus,
> >> http:// should be shown again, IMO.
>
> >> And, frankly, I don't get why somebody thought that there's a need
> >> to hide http:// in the first place. Stupid idea. On space limited devices
> >> like mobile phones, it makes sense (that's why Mobile Safari on iPhone
> >> is correct in doing so).
>
> >> Alexander
>

> >> 2010/4/15 Andrew Benton <andrewmben...@gmail.com>

>
> >> no need to get hostile. i actually am interested in various ways that
> >>> removing http:// might be an annoyance, and so far i have one
> >>> excellent answer and a pointer to a few bugs that should alleviate
> >>> that particular annoyance. i'm wondering if there are others...
>

> >>> On Wed, Apr 14, 2010 at 1:03 PM, Artem Mikhmel <amikh...@gmail.com>

> >>> wrote:
> >>> > Sure, if you don't understand, nobody shouldn't.
>

> >>> > On 14 April 2010 21:26, Andrew Benton <andrewmben...@gmail.com> wrote:
>
> >>> >> i'm not understanding how it is an inconvenience. Copying to the
> >>> >> clipboard isn't an issue since the http:// is prepended in that case.
> >>> >> what other inconveniences are there?
>
> >>> >> On Wed, Apr 14, 2010 at 11:20 AM, Graham Triggs <

> >>> grahamtri...@gmail.com>

> >>> >> wrote:
>
> >>> >> > It's very simple. It could be optional to display the protocol. It
> >>> >> > could [also] be optional to display the protocol in a fainter colour
> >>> >> > (ie. medium grey).
>
> >>> >> > Both of these would allow you to glance at the address bar with
> >>> fewer
> >>> >> > distractions.
>
> >>> >> > But to simply force removing the protocol on everyone is not the way
> >>> >> > to go - it's seriously inconveniencing a good number of people
> >>> (myself
> >>> >> > included).
>
> >>> >> > On Apr 13, 5:58 pm, Caleb Eggensperger <caleb...@gmail.com> wrote:
> >>> >> >> I, for one, much prefer not having the protocol -- it makes the
> >>> address
> >>> >> >> bar
> >>> >> >> easier to read at a glance and it removes extraneous information.
>
> >>> >> > --

> >>> >> > Chromium Discussion mailing list: chromium-disc...@chromium.org

> >>> >> > View archives, change email options, or unsubscribe:
> >>> >> >    http://groups.google.com/a/chromium.org/group/chromium-discuss
>
> >>> >> --

> >>> >> Chromium Discussion mailing list: chromium-disc...@chromium.org

> >>> >> View archives, change email options, or unsubscribe:
> >>> >>    http://groups.google.com/a/chromium.org/group/chromium-discuss
>
> >>> --

> >>> Chromium Discussion mailing list: chromium-disc...@chromium.org

> >>> View archives, change email options, or unsubscribe:
> >>>    http://groups.google.com/a/chromium.org/group/chromium-discuss
>
> >> --
> >> Alexander
> >> --
> >> ↯    Lifestream (Twitter, Blog, …) ↣http://alexs77.soup.io/    ↯

> >> ↯ Chat (Jabber/Google Talk) ↣ a.sk...@gmail.com , AIM: alexws77  ↯
>
> >>  --
> >> Chromium Discussion mailing list: chromium-disc...@chromium.org

> >> View archives, change email options, or unsubscribe:
> >>http://groups.google.com/a/chromium.org/group/chromium-discuss
>
> --
> Alexander
> --
> ↯    Lifestream (Twitter, Blog, …) ↣http://alexs77.soup.io/    ↯

> ↯ Chat (Jabber/Google Talk) ↣ a.sk...@gmail.com , AIM: alexws77  ↯

[Alexander Skwar]

I do keep it civilized. The change was stupid. It was also rather

unclever, to not *first* start a discussion.

What annoys me, is that this change really was so totally unrequired.

Or rather, I don't understand which problem was solved. As it is now,

the addres bar is messier, because it's missing important information.

Before, it was clean.

Also, why add complexity here? What's the point?

I just don't get it.

2010/4/15 Philip Kahn <tigerh...@gmail.com>

--
Chromium Discussion mailing list: chromium...@chromium.org

View archives, change email options, or unsubscribe:
   http://groups.google.com/a/chromium.org/group/chromium-discuss

--
Alexander
--
↯    Lifestream (Twitter, Blog, …) ↣ http://alexs77.soup.io/     ↯

↯ Chat (Jabber/Google Talk) ↣ a.s...@gmail.com , AIM: alexws77  ↯

[Philip Kahn]

It has been discussed -- since November 2009! (It's even in the
title!).

See: http://code.google.com/p/chromium/issues/detail?id=27570

I don't see how it's missing important information, anyway. You're
told when you're on a secure connection; in all other cases (eg, the
vast majority of internet pages) it hides otherwise identical,
superfluous information. In underscoring the change between non-https
and https it helps make general users more secure in their computing.

On Apr 15, 1:24 am, Alexander Skwar <a.sk...@gmail.com> wrote:
> I do keep it civilized. The change was stupid. It was also rather
> unclever, to not *first* start a discussion.
>
> What annoys me, is that this change really was so totally unrequired.
> Or rather, I don't understand which problem was solved. As it is now,
> the addres bar is messier, because it's missing important information.
> Before, it was clean.
>
> Also, why add complexity here? What's the point?
>
> I just don't get it.
>

> 2010/4/15 Philip Kahn <tigerhawk...@gmail.com>

[Alexander Skwar]

Ah, I thought discussions should take place on a mailing list

and not in bug reports. Okay, got that now.

I disagree that "http://" is superflous, though. Granted, it /might/

be superflous for reading "with the eyes". But it's NOT AT ALL

superflous, if you want/must deal with the address (an indication

for this would be, that the address bar / Omnibox has got the

focus). In that case, the complete adress must be shown, and

this includes the protocol!

For normal surfing (ie. clicking on links) it can be discussed if

it's a good/bad idea to hide the protocol.

But as I said, I don't get what problem was solved by hiding http://.

It doesn't make the normal surfing or using the browser any easier

or more secure. It's a good move, though, that https:// is highlighted

and also that it's strongly highlighted, if the certificate is bad (like on

the example site https://libmpq.org/). That's "in your face" and that's

a good idea in this case!

2010/4/15 Philip Kahn <tigerh...@gmail.com>

Chromium Discussion mailing list: chromium...@chromium.org

View archives, change email options, or unsubscribe:
   http://groups.google.com/a/chromium.org/group/chromium-discuss

--
Alexander
--
↯    Lifestream (Twitter, Blog, …) ↣ http://alexs77.soup.io/     ↯

↯ Chat (Jabber/Google Talk) ↣ a.s...@gmail.com , AIM: alexws77  ↯

[Simon B.]

Some questions are clearing up, like with crbug.com/41489 being
marked Labels: Mstone-5 ReleaseBlock-Stable by pkasting (thanks!)
and I was just about to start liking the change.
But then I read http://code.google.com/p/chromium/issues/detail?id=41493#c4
and now I'm back at wondering -- what were the advantages and reasons
for removing "http://" again?

/Simon B.

[Ben]

Pardon my asking, but what about ftp://? Is that hidden too, or is it shown?

I realize it's less common, but sometimes people might like to know
whether they're browsing an ftp server using ftp or http, since it could
make a difference (however slight). There are servers which use multiple
protocols to serve the same data on the same domain:

http://mirrors.kernel.org/ubuntu-releases/
ftp://mirrors.kernel.org/ubuntu-releases/

[Alexander Skwar]

Ben,

ftp:// is shown. However, with ftp, there are other issues.

http://code.google.com/p/chromium/issues/detail?id=41585
http://code.google.com/p/chromium/issues/detail?id=41586

If you're on http://ftp.mozilla.org/pub (or any other FTP
server which also has a http:// / web server running on
it and which starts with ftp.) and hit enter in the Omnibox
or hit the "go" button, you're all of a sudden on the ftp://
server, even if you were on the http:// server originally.
It might sound silly to just hit <enter> in the omnibox,
but suppose you're on http://ftp.mozilla.org/pub and now
enter a path, you're then on ftp.mozilla.org/pub/zz and
this takes you to the ftp server. Broken-by-design, if you
ask me.

2nd bug: you went to http://ftp.mozilla.org/pub/. Then Chrome
will only show ftp.mozilla.org/pub/. If you copy that to the
clipboard, only ftp.mozilla.org/pub/ is copied - the http://
is missing. Broken-by-design, if you ask me.

To extend what Ben said: There are servers which serve
the SAME content on ftp:// and http://. If it's the SAME
content, then it doesn't matter much, if ftp or http is used
(usually). But there are also servers, which serve (or
behave) DIFFERENT content, depending on http:// or
ftp:// access (eg. http://ftp.ugs.com/ vs. ftp://ftp.ugs.com/).

IMO the whole "hide http:// design" is broken, as far as
I'm concerned. But that might be, because I just don't under-
stand WHY this decision has been made. What problem
was (supposedly) solved by doing so?

I also find it VERY annoying, that there was no discussion
on this mailinglist. "Hiding" *DISCUSSIONS* on the bug
tracking system is, uhm, suboptimal, I'd say.

Alexander

2010/4/15 Ben <benj...@gmail.com>:

[dhw]

And another protocol copy/paste error you can add a STAR to:

http://crbug.com/41639 : ctrl-c and ctrl-insert trigger different
copying behavior

[dhw]

And also:

http://crbug.com/41490 : Copying urls / dragging urls behavior,
clarified

[Alexander Skwar]

Strange... So many errors, so much work and time required
to fix this. For what gain? Why hide http://? Don't you guys
have more important things to do and fix, then to waste time
on making addressbar usable again after breaking it massively
by dumping important information from it?

2010/4/15 dhw <d...@chromium.org>:

> And also:
>
> http://crbug.com/41490 :  Copying urls / dragging urls behavior,
> clarified
>

--

[Brian Rakowski]

Thanks for all the feedback. We are listening. It's important that we can keep trying new things on the dev channel to see how they feel and get useful feedback. If possible, please help us keep the discussion civil and productive.

In this case, we're trying to address a bunch of the copy/paste issues that make this change really annoying so we can see if the change is beneficial when those issues don't get in the way. 

To state clearly what the motivation behind the change was, we just wanted to simplify the address bar. Users shouldn't need to deal with typing, or mentally parsing out, the "http://" that prepends the vast majority of URLs.

Thanks,

Brian

--

[dhw]

Glad to hear all the copy/paste problems will be promptly addressed.

Just another one to add to the list:

http://crbug.com/41609 : Modifying Omnibox URL prevents scheme from
being copied

And now there's a new label "HTTPStripping" for all these bugs:

http://code.google.com/p/chromium/issues/list?q=label:HTTPStripping

[Alexander Skwar]

I agree that it's a good thing, that users don't have
to type in http:// normally (unless in corner cases
like http://ftp.mozilla.org and the like). But wouldn't
the easier solution for "mentally parsing out http://
in front of URLs" be, that http:// is there, but shown
very dim (eg. light gray on white, or something like
this)?

I could imagine that there could be 3 colors - light
gray for http://, black for server name, and gray for
path/query (ie. everything after the server name).
Kinda like this (HTML required in mail or attached

image or at img248.imageshack.us/i/bildschirmfoto20100415ux.png/ -

hah! http:// missing :(( ):

http://mail.google.com/mail/?shva=1#inbox/127f76790e4f6b0d

This would solve all sorts of problems - users always

can see the protocol, but highlight clearly is on server

name, because that's what users are probably most

interested in. This could also do away with all these

heuristics and might make the address bar easier and

thus less buggy again.

I really do _not_ think that hiding http:// makes anything

easier at all. In the contrary - it makes it more complicated,

even for "normal users", because they sometimes (eg. on

their banking site) see that "strange" https:// or something

like ftp://, sometimes even see http:// (if http://crbug.com/41585#c10 (2)

is implemented) and sometimes see nothing in front of the

server name. If that's not confusing, then I don't know what

is.

If "color schemes" (see above) were used, basically all of

these issues go away. PLUS the users gets focussed on

the server name.

Alexander

2010/4/15 Brian Rakowski <br...@chromium.org>:

[PJC]

On Apr 15, 8:30 pm, Alexander Skwar <a.sk...@gmail.com> wrote:
> I agree that it's a good thing, that users don't have
> to type in http:// normally (unless in corner cases

> likehttp://ftp.mozilla.organd the like). But wouldn't

> the easier solution for "mentally parsing out http://
> in front of URLs" be, that http:// is there, but shown
> very dim (eg. light gray on white, or something like
> this)?
>

As far as I'm aware, I haven't had to *type* http:// in the last 3 or
so years. If it's not typed, it's assumed, but I like that it's
shown.

> I could imagine that there could be 3 colors - light
> gray for http://, black for server name, and gray for
> path/query (ie. everything after the server name).
> Kinda like this (HTML required in mail or attached
> image or at img248.imageshack.us/i/bildschirmfoto20100415ux.png/ -
> hah! http:// missing :(( ):
>

> http://*mail.google.com*/mail/?shva=1#inbox/127f76790e4f6b0d

>
> This would solve all sorts of problems - users always
> can see the protocol, but highlight clearly is on server
> name, because that's what users are probably most
> interested in. This could also do away with all these
> heuristics and might make the address bar easier and
> thus less buggy again.
>

I like this idea of different colours, though to be honest, it's never
bothered me that everything has been there.

> I really do _not_ think that hiding http:// makes anything
> easier at all. In the contrary - it makes it more complicated,
> even for "normal users", because they sometimes (eg. on
> their banking site) see that "strange" https:// or something
> like ftp://, sometimes even see http:// (ifhttp://crbug.com/41585#c10(2)
> is implemented) and sometimes see nothing in front of the
> server name. If that's not confusing, then I don't know what
> is.
>

If http:// is to be hidden, then surely https:// ftp:// and file://
should *also* be hidden, with appropriate icons being used in their
place. To my mind the inconsistency of hiding http: yet showing
https, etc, just makes things more confusing.

Is this a proposal for the future?

> If "color schemes" (see above) were used, basically all of
> these issues go away. PLUS the users gets focussed on
> the server name.
>

Agreed, I tend to prefer this to removing http://, etc, but if one is
removed, then all should be, purely for consistency.

> Alexander
>

I also fail to understand *why* this was done. To say this reduces
user confusion is, I feel, misleading. ALL other browsers show the
protocol in-use, so people -- yes, normal people -- are *used* to
seeing it there. Personally, I feel that removing it from chrome
while it remains in all other browsers is a mistake.

-PJC

[Caleb Eggensperger]

On Fri, Apr 16, 2010 at 03:06, PJC <pcut...@gmail.com> wrote:

As far as I'm aware, I haven't had to *type* http:// in the last 3 or
so years.  If it's not typed, it's assumed, but I like that it's
shown.

Showing the http in the location bar misleads less tech-savvy users into thinking it has to be typed. I know this is just anecdotal, but I have told my father repeatedly that he doesn't have to type the http://, yet he continues to. Perhaps this change will finally break him of the habit, in which case I would consider that a benefit to him, and probably others.

[Alexander Skwar]

But would it be bad, if http:// was typed? Better to type

in something which isn't absolutely required, then to leave

out important things.

If a user wanted to go to a webserver running on ftp.mozilla.org,

he'd need to type in http://ftp.mozilla.org/. What's so bad about

entering something more complete then it absolutely has to?

OTOH, if http:// was always hidden, users might get too

used to omitting the http://, even if it would be required (see

my web-on-ftp server example above).

2010/4/16 Caleb Eggensperger <cale...@gmail.com>

--
Alexander
--
↯    Lifestream (Twitter, Blog, …) ↣ http://alexs77.soup.io/     ↯
↯ Chat (Jabber/Google Talk) ↣ a.s...@gmail.com , AIM: alexws77  ↯

[fonix232]

In snapshot 44876 the https:// protocol returns, but in a weird way
(the usual protocol is a bit light gray, but it is blue, I think it is
rgb 0,0,255)
Still no http:// :S

On ápr. 13, 08:05, Artem Mikhmel <amikh...@gmail.com> wrote:
> Turn back on a protocol name in the address bar, please!

[farout]

NO do not turn Turn back on a protocol name in the address bar,
please!

It is all about simplicity
Which is simpler and easier to read and understand what it means?

BAD - http://www.glennbeck.com/828/

Better - www.glennbeck.com/828/

Better still - www.glennbeck.com [828]^

GOOD - Glenn Beck's "Restoring Honor" Rally Supports Special Ops
Troops ...(the URL is hidden but accessable)

Chrome is about translation between languages this last example is
easiest to read and understand as it is a translation of the
technospeak to the search engine page entry. The omnibox should
automatically translate from technospeak as it does now reverse
translating keywords to search request technospeak.

Get the whole enchilada. Make the omnibox a drop down.
the first line is the anchor text that was clicked to open the page
(highlighted on the source page if back button pressed)
the second line is the key words that were used in the search engine
(if page was opened from a search page entry) (right click to find on
page)
the third line would be visited pages subtabbed in the domain (similar
to W7 basically extends the chrome tabbing system in contextual way)
the forth line would be the gibberish(with the http:// )(this data
would be combined with the 1st data in HTML anchor tag on right click
copy to clipboard)

Make these 4 datums accessible from the java script and a right click
menu.

farout

PS
You could do this in an extension but it would necessarily be
duplicate code and it is basic to browsing so should be standard in
the browser.

[Hauke Laging]

Am Sonntag 18 April 2010 20:43:51 schrieb farout:
> NO do not turn Turn back on a protocol name in the address bar,
> please!
>
> It is all about simplicity

Are you disputing about the default setting or the possibility itself?

Is there any argument against making this configurable? I think it's OK to
make the variant without the protocol the default.

> Which is simpler and easier to read and understand what it means?
>
> BAD - http://www.glennbeck.com/828/
>
> Better - www.glennbeck.com/828/
>
> Better still - www.glennbeck.com [828]^

The best would be an easy to read combination of the last two that does not
break any convention:

www.glennbeck.com /828 /foo /bar.html
But the whitespace should be shown only not be real content. This would be
similar to the Firefox add-on Locationbar:

https://addons.mozilla.org/de/firefox/addon/4014

I often do that in HTML pages. I seperate (mostly) digits by CSS margins. You
can easily read that but if you mark and copy the content then there are no
seperation spaces:

12<span style="margin-left:0.2em;margin-right:0.2em;">34</span>56

And one more proposal for a compromise: Show the http:// when the URL is
marked (and probably copied). Show it after clicking into the box. The the
user can decide what to mark. A double click could mark the URL without
http://, a triple click include that.

CU

Hauke

[Alexander Skwar]

Oh, wonder! I disagree :) from the examples that have been presented,
I think the first (ie. with http and all) is best. Reason: it's
easiest to understand, because it's what everybody is used to. The 3rd
example is of course the worst. One of the reasons is, that I can
hardly see how it would scale.

Alexander

[Alexander Skwar]

Showing the http protocol string after the omnibox gets the focus has
been suggested. I think it's bad. Reason: makes the content in the
omnibox jump. This would make it hard/impossible to select the right
thing. What makes it hard, is that the user can click into the omnibox
and directly drag left/right to select.

Solution: ALWAYS show the protocol. Best compromise I can think off:
make it so, that the protocol is not visible directly. It should be
scrolled out-of-bounds and the user should e able to scroll to the
left and then see (and thus highlight) the protocol.

Alexander

[Hauke Laging]

Am Sonntag 18 April 2010 21:14:19 schrieb Alexander Skwar:
> Showing the http protocol string after the omnibox gets the focus has
> been suggested. I think it's bad. Reason: makes the content in the
> omnibox jump.

Not necessarily. You can extend the omnibox to the left to the length coveres
by "http://" while it has the focus so that the absolute position of the rest
of the URL stays the same.

If the width of the symbol at the left end of the omnibox is slightly
extrended to the length of the string "http://" then nothing outside the box
would be affected.

In the rare case that you click into the omnibox and decide afterwards that
you would like to drag the bookmark symbol to the bookmark bar you click
somewhere else or press Esc.

Problem solved.

Hauke

[Alexander Skwar]

Hi!

Hm, isn't that (more or less…) the same solution
that I suggested? :) Ie. make it so, that http:// is
"scrolled out" of the visible area? :)

But if understand you right, you suggest that the
"globe" icon should be so wide, that it covers
"http://" normally? And as soon as mouse hovers
over the omnibox, icon should go away?

If so - yeah, sounds good to me. Maybe even
better then my original idea.

Cheers,
Alexander

2010/4/18 Hauke Laging <acco...@hauke-laging.de>:

--
Alexander
--
↯  Lifestream (Twitter, Blog, …) ↣ http://alexs77.soup.io/ ↯
↯ Chat (Jabber/Google Talk) ↣ a.s...@gmail.com , AIM: alexws77 ↯

[farout]

A committee is the only known form of life with a hundred bellies and
no brain.
Robert Anson Heinlein (from the Collected Notebooks of Lazarus Long,
Time Enough for Love, 1973)


Design By Committee
http://www.c2.com/cgi/wiki?DesignByCommittee

Problem: Given a political environment in which no one person has
enough clout to present a design for a system and get it approved, how
do you get a design done?
Forces: Often, a problem can be clearly identified for which no
existing solution fits well. For instance, the DOD figured out in the
mid-late '70s that the existing programming languages that were being
used for big military projects just didn't cut it. FORTRAN, JOVIAL and
COBOL were not going to allow programmers to write the programs
necessary to build things like SDI -- they didn't provide large-scale
programming support, encapsulation, or a host of other things that
language designers had decided that were needed. However, no one had
the force of personality or knowledge to drive through a single,
consistent solution. There was no AlanKay or GraceHopper to provide a
vision. So they:
Solution: Put together a big committee to solve the problem. Let them
battle it out amongst themselves and finally take whatever comes out
the end.
Discussion: The problem with DesignByCommittee is that everyone on the
committee has their own vision of the final product. They each fight
to get their $0.02 added in to the final version. Since there is no
unifying vision, what results is a mish-mash of features in which
everybody gets their share put in. By the way, this story relates how
the AdaLanguage came about.

For the record: Ada was designed by Jean Ichbiah, who sometimes vetoed
committed decisions that were 12-to-1 against him, see
http://www.adapower.com/articles/popularity.html (NanningBuitenhuis?).

Where is your vision guys????
SO VERY GOOD - The anchor text is what is visible in the omnibox, the
URL is hidden or in drop down list but accessible using right click or
ctrl C)
This is consistent with the chrome developers group vision but it will
be up to the individual developer if or when it might get done.

farout

[Thierry Boileau]

Hi farout,

For the record: Ada was designed by Jean Ichbiah, who sometimes vetoed
committed decisions that were 12-to-1 against him, see
http://www.adapower.com/articles/popularity.html (NanningBuitenhuis?).

do you mean?
http://www.adapower.com/index.php?Command=Class&ClassID=Advocacy&CID=39


best regards,
Thierry Boileau

[Timothy Zorn]

Quite simply:

Say I'm on the website "http://oneplus.net/one"
In the URL bar, it says "oneplus.net/one"

Ok, now say I want to copy just "oneplus.net"
I do not want the "http://" to be copies or the "/one"

These are the contents of my clipboard after attempting: "http://oneplus.net/"

This is undesired and quite ridiculous. Don't mess with my clipboard. Don't mess with my address bar. Stop hiding things from users because you think they're dumb.

If the address bar showed the full "http://oneplus.net/one", I would not run into this problem.

[john bailey]

Timothy hit the nail on the head!

[Brantley Blanchard]

Don't forget intranet sites.  Our local wiki is simply http://wiki/ and our build server is http://bld-team03/all/IncrementalBuild.  If I want to check on team04's incremental build, you would think I could simply change the 3 to a 4.  You would be wrong.  Instead of hitting our intranet site, it does a google search of "bld-team04/all/IncrementalBuild".  Poor UX indeed.

I haven't tried it myself but I wonder if the same things happens for localhost.  That would really suck for webdevs if it did.

[PhistucK]

Though it does show an information bar that lets you go to the intranet site, right?

If you use it, I think it remembers it.

☆PhistucK

--

--
Chromium Discussion mailing list: chromium...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-discuss

---
You received this message because you are subscribed to the Google Groups "Chromium-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-discu...@chromium.org.

[PhistucK]

One character in the origin part, or in the part following the origin (after the first single /)?

The former makes sense, the latter does not make a lot of sense and might be a bug (crbug.com is the place for such).

☆PhistucK

On Fri, Apr 29, 2016 at 9:08 PM, Brantley Blanchard <brantley....@channeladvisor.com> wrote:

if I'm reloading the page, it remembers that.  Change one char in the URL however and it does a search.

[Brett Wilson]

On Friday, April 29, 2016 at 9:32:02 AM UTC-7, Brantley Blanchard wrote:

Don't forget intranet sites.  Our local wiki is simply http://wiki/ and our build server is http://bld-team03/all/IncrementalBuild.  If I want to check on team04's incremental build, you would think I could simply change the 3 to a 4.  You would be wrong.  Instead of hitting our intranet site, it does a google search of "bld-team04/all/IncrementalBuild".  Poor UX indeed.

I haven't tried it myself but I wonder if the same things happens for localhost.  That would really suck for webdevs if it did.

This URL should generally navigate automatically. There is some weirdness here, I filed https://bugs.chromium.org/p/chromium/issues/detail?id=608861 for this issue.

Once you've navigated to a host, it should remember that it's a host and not a search, so should default to navigating in the future.

Brett