Closed Bug 228524 (no-urlbar) Opened 19 years ago Closed 11 years ago

Replace URLbar with domain, owner and search fields


(SeaMonkey :: Location Bar, enhancement)

Not set


(Not tracked)



(Reporter: BenB, Assigned: BenB)



(6 files, 1 obsolete file)

As an extension to bug 184881, I'd like to present the following idea for
discussion. I know it is extremely controversial, to the point of being
ridiculous to some at first.

First, please shortly read over bug 184881, at least until comment 8.

The goals is this bug are
1. to clearly show the user which trust realm he is in, with as little risk for
confusion as possible, also suitable for bloody newbies.
2. to natually lead users the right way to find sites and estabish trust with them.
3. to make the browsing experience less confusing for them.

For 1., this means to make spoofing (bug 122445) impossible.
For 2., this means to avoid domain guessing (Company ->, which
often goes wrong, possibly dangerously wrong.
For 3., it may help to remove URLs from their view, because they were not meant
and often are not suitable for human consumption anyways.

Just adding the SSL cert owner prominently in the toolbar (bug 184881) won't
help with spoofing, if you still display the URLbar, because the user will see
"" in the URLbar and hostname "234.567.891.234", and will
think "Microsoft, OK".

I would go one drastical step further, namely completely removing the URL bar
and replacing it with only a hostname field, one for the cert owner (for HTTPS)
or the domain owner (for HTTP/FTP etc., via whois, if we are allowed to query it
so often, compare Alexa's former What's Related sidebar plugin).

URLs would usually be opened via links in webpages (possibly from third
parties), bookmarks or external applications.

URLs found in advertizements are rare and can be opened via File|Open, like we
do with almost every other kind of application. URLs found in other applications
(e.g. email) are *hopefully* clickable, otherwise you could use File|open as
well. If necessary, we could provide a toolbar button for that - it would even
*reduce* the amount of clicks needed to enter a URL, for the average user,
assuming the URL field in the dialog is empty when opened.

For first-time visits of a company's website, e.g. known from offline world,
without knowing a URL, the search field would be there to give better results
(based on e.g. dmoz, Google etc.) than domain guessing.

Once you found an interesting company / site, you bookmark it. Unlike repeated
searching, this ensures that you always end up at the site you remember, even if
it had an hard-to-remember or unguessable domain name. It also allows browsing
with the mouse.

For keyboard-heavy users, the search field could be extended to show results
from bookmarks first, with additional shortcuts (e.g. Shift-Enter) to go
directly to the best result.

For exporting URLs into other applications / environments, you can ideally use
File|Send Link. That doesn't work for ICQ etc., so for them, you could use the
page proxy icon. (What about mutt etc.? Can I drag a text into a shell?) This is
probably the weakesst point in the proposal, though.

Some people like to see the URL to see where they are on the site. However,
URLs, as mentioned, are usually not meant or suited for human consumption. Many
of them are very long and/or not understandable for visitors. Webpages
themselves usually provide site orientation and navigation, which is much more
suitable for humans and usually much faster (one click vs. text editing).
Standarized sitemaps (bug 131160) would improve that even more.

Concrete changes suggested (to toolbar):
- Remove URLbar (from default setup, but still allow to add it via toolbar
- Add (read-only) field for hostname, right-aligned
- Add (read-only) field for SSL cert owner (where possible) or domain owner
(otherwise; if possible)
- Keep drag&droppable page proxy icon
- Probably add Open button
- Possibly add Page Info button, showing a simplified Page Info dialog, with
  - hostname
  - URL
  - SSL cert
  - Domain registration record and
  - other easily-understandable and essential information about a page.
- Possibly implement sitemap (bug 131160)

I was playing with the idea of implementing it in an experimental,
newbie-orientated browser, but didn't have the motivation and time for it yet.
whois information was not meant to be used in this fashion. People do not want
their name and address shown when someone visits their site.
Also this will slow down mozilla.

Removing the URL is too damaging to the functionality of the browser as we know it. 
This might not be the exact solution, but it is definitely the right direction. 

The problem with the current URL bar is that is reflects both "location" (where
I am now) and is used for "go"ing (where do I want to go).

If we could break the two functions appart, then a more sophisticated display,
like this, would be good.
Attached image mockup screenshot (obsolete) —
I like thise idea. Attached a screenshot of a mockup of some way to implement
this. A tooltip with more information about the location.

random brainstorming:

My current ways of going to a site (and i am a more experienced user, so i use
more advanced ways):
- bookmarks (and pers. toolbar)
- typing domain (with autocomplete)
- sometimes completing to path, but i could just make a bookmark.
- in very few occasions: changing path.
and i don't use it, but i have seen others do it: the pulldown thing in the url

But i almost never saw anybody (except for web developers) type in more than a

The url bar is a quick way to enter a domain. ctrl-l or some menu is something
i don't use. I like the quick access to the url bar.

It would be ok to only see the domain of where i am currently, and be able to
find out the domain easily, but hidden by default (like a tooltip).

The domain indicator could become a input box to type a domain, with
domain-only autocompleting. In the cases i want to autocomplete the path, i
could open a dialog.
I have a prototype of this working.

Only the hostname is shown in the toolbar (it's still technically the URLbar,
because the browser code is too "interwooven" to remove it easily). I show the
full server name, but remove "www.". The page proxy icon stays (it's much more
important now).

I moved the security icon/button from the status bar to the toolbar, under the
page proxy icon. Under the hostname appears the SSL cert owner. Both are hidden
for non-SSL sites.

A click (in contrast to drag) on the proxy icon opens the Page Info dialog. I
added an "Overview" tab to it, with the information which is more relevant for
normal users. It's currently missing SSL info, the overview should show cert
owner, organisational unit and cert issuer name, as well as the encryption
strength (no/low/high).

As replacement for the urlbar is now a search bar. Entering text and hitting
Return sends you to google search results. SHIFT-Return uses Google's "I'm
feeling lucky" to directly go to the highest-ranked search result. So, you can
enter "CNN" and hit SHIFT-Return and you end up directly at
<>. Adding CTRL opens in new window/tab, as known from urlbar.

I'm attaching a few screenshots.
Alias: no-urlbar
Attached image Normal HTTP site
Attachment #139382 - Attachment is obsolete: true
Attached image HTTPS site
Attached image Page Info Overview tab
Attached image Search / Keywords
There's lots of stuff missing, e.g.:
- hostname should be left-aligned, but overflow/crop on the left,
  if it's too long, so that the right part always visible.
- "Open" button to load a URI from external sources.
- Security properties in Page Info Overview, as mentioned.
- Maybe load domain owner (in page info and maybe even toolbar),
  similar to Alexa's What's Related sidebar.
- Make stuff comfortable to use.
- Think about migrating users.
Attached image Spoof test
This is the URL spoofing test from

BTW: I just needed to copy the above URL and could just drag the page proxy
icon into the textfield.
- Adapt status bar / link hover code
Great step in this direction, but I have a few comments and suggestions:

For starters, the WHOIS domain "owner" information should NOT be trusted.  I 
could pretty easily register a new domain with a fictitious company name, 
possibly one confusingly similar or identical to a corporation I want to 
spoof.  While it isn't necessarily bad to show this, it should be VERY clear 
that this isn't to be trusted as much as an SSL identity.

Secondly, some hint that a domain name alone should be considered untrusted 
might be nice.  If we want to display the domain name for a non-authenticated 
(non-SSL) connection, maybe a little icon or blurb indicating that the session 
is unauthenticated would be warranted.

I might also like to see this taken a little further and make it clear what (if 
any) client SSL cert is used to authenticate the client to the server.  You 
could even go a little crazy and include HTTP auth as some form of weak 
authentication and make that apparent as well.

All in all, I think this is a great move forward.  How about trying this in its 
own toolbar?  Similar to the Links tool bar, it could have an option to 
automatically appear only when information about the "trust" of the connection 
is available (entering an authenticated SSL connection, or where the URL looks 

The biggest thing against a solution like this is efficient use of screen real-
estate, so if it's going to work for any Mozilla implementations, it's gotta do 
what it needs to do without cluttering things up.
(In reply to comment #13)
> For starters, the WHOIS domain "owner" information should NOT be trusted.  I 

Besides that, networksolutions (or whoever own the whois servers) isn't going to
like mozilla to lookup stuff for every page. We could cache lookups, but it will
still be a lot of added requests.
Besides that, tehre is a technical difficulty that whois is a free format afaik.
It's hard to filter out the owner, and you are at the mercy of the provider not
to change the format.

> Secondly, some hint that a domain name alone should be considered untrusted 
> might be nice.  If we want to display the domain name for a non-authenticated 
> (non-SSL) connection, maybe a little icon or blurb indicating that the session 
> is unauthenticated would be warranted.

99% percent of the sites i visit are untrusted. I will quickly mentally filter
the icon out, and not notice it anymore. As such, it won't work.

> All in all, I think this is a great move forward.  How about trying this in its 
> own toolbar?

Isn't the intention to replce the urlbar? so why an own toolbar. In my opinion,
users don't need the full url bar. They don't even know what the path part
means. So why display it always while only the domain would do?

Sure, there must be an easy way to find out the path, and to edit it. But not in
the primary display.
Wow, I am starting to think that thid might actually work! We would still need a
pref to bring the URL bar back for those users who are too annoyed by this
change (and users who need to manually edit URLs a lot for some reason), but for
the rest of the users this would actually make life much simpler. 

The pref will probably need to be easy to access and switch in _both_
directions, so that people who like the new design, but still want quick manual
editing of URLs at times, can easily switch from one to another. My suggestion
would be to attaching a context ("right-click") menu to the proxy icon and add
the pref there.
How about a new toolbar containing the old urlbar, hidden by default? if you
want quick access, use the grippies :)
Component: XP Apps: GUI Features → Location Bar

That sucks, a lot. CAs suck. Thanks, GeoTrust, for the hint, though.
Grr.. so some CAs do vouch for organizational identity and others do not..? 
Maybe the field could selectively appear only for CAs known to perform this
Product: Core → SeaMonkey
Summary: Replace URLbar with hostname, owner and search fields → Replace URLbar with hostname/domain, owner and search fields
Summary: Replace URLbar with hostname/domain, owner and search fields → Replace URLbar with domain, owner and search fields
Closed: 11 years ago
Resolution: --- → WONTFIX

Please, no insults. In fact, it's pretty much what Firefox is doing today. At least the direction.

And this bug was filed exactly 8 years ago.
You need to log in before you can comment on or make changes to this bug.