Last Comment Bug 366797 - Revise the Location Bar (highlight effective domain, decode URLs, add overflow ellipsis & tooltip)
: Revise the Location Bar (highlight effective domain, decode URLs, add overflo...
Status: RESOLVED FIXED
:
Product: Firefox
Classification: Client Software
Component: Location Bar (show other bugs)
: Trunk
: All All
: -- enhancement with 9 votes (vote)
: Firefox 3 alpha6
Assigned To: Dão Gottwald [:dao]
:
Mentors:
http://wiki.mozilla.org/Firefox3/Loca...
: 305132 405099 (view as bug list)
Depends on: 408890 342314 364129 368263 368989 382220 386727 386741 386759 386896 387077 387723 388371 389189 390333 394667 397815 400809 406222 408891 410726 451833
Blocks: 105909 190615
  Show dependency treegraph
 
Reported: 2007-01-12 02:45 PST by Dão Gottwald [:dao]
Modified: 2013-09-17 07:25 PDT (History)
78 users (show)
stephen.donner: in‑litmus?
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
patch (10.87 KB, patch)
2007-01-14 16:31 PST, Dão Gottwald [:dao]
no flags Details | Diff | Splinter Review
patch 2 (10.92 KB, patch)
2007-01-16 16:54 PST, Dão Gottwald [:dao]
mbeltzner: ui‑review-
Details | Diff | Splinter Review
WIP 3 (12.74 KB, patch)
2007-01-17 04:40 PST, Dão Gottwald [:dao]
no flags Details | Diff | Splinter Review
WIP 4 (11.83 KB, patch)
2007-01-17 06:23 PST, Dão Gottwald [:dao]
no flags Details | Diff | Splinter Review
WIP 4 (had typo) (11.83 KB, patch)
2007-01-17 06:29 PST, Dão Gottwald [:dao]
no flags Details | Diff | Splinter Review
patch 5 (13.03 KB, patch)
2007-01-17 16:28 PST, Dão Gottwald [:dao]
no flags Details | Diff | Splinter Review
patch 6 (15.48 KB, patch)
2007-01-18 07:27 PST, Dão Gottwald [:dao]
no flags Details | Diff | Splinter Review
patch 6 (15.46 KB, patch)
2007-01-18 07:32 PST, Dão Gottwald [:dao]
no flags Details | Diff | Splinter Review
patch 7, using mouseover (13.90 KB, patch)
2007-01-19 07:11 PST, Dão Gottwald [:dao]
no flags Details | Diff | Splinter Review
patch 7, cleaned up (14.30 KB, patch)
2007-01-20 01:59 PST, Dão Gottwald [:dao]
no flags Details | Diff | Splinter Review
patch 8, using the location object (14.28 KB, patch)
2007-01-20 05:45 PST, Dão Gottwald [:dao]
no flags Details | Diff | Splinter Review
real patch 8 (14.26 KB, patch)
2007-01-20 05:53 PST, Dão Gottwald [:dao]
no flags Details | Diff | Splinter Review
patch 9, nsIURI instead of location (14.65 KB, patch)
2007-01-20 17:10 PST, Dão Gottwald [:dao]
no flags Details | Diff | Splinter Review
patch 10 (14.79 KB, patch)
2007-01-21 15:45 PST, Dão Gottwald [:dao]
no flags Details | Diff | Splinter Review
WIP 11 (16.75 KB, patch)
2007-01-22 17:14 PST, Dão Gottwald [:dao]
no flags Details | Diff | Splinter Review
patch 12 (17.39 KB, patch)
2007-01-23 04:11 PST, Dão Gottwald [:dao]
no flags Details | Diff | Splinter Review
patch 12 (17.42 KB, patch)
2007-01-23 04:45 PST, Dão Gottwald [:dao]
no flags Details | Diff | Splinter Review
patch 13 (17.26 KB, patch)
2007-01-25 07:08 PST, Dão Gottwald [:dao]
no flags Details | Diff | Splinter Review
patch 14 (18.61 KB, patch)
2007-01-26 08:14 PST, Dão Gottwald [:dao]
no flags Details | Diff | Splinter Review
patch 15 (18.58 KB, patch)
2007-01-27 01:45 PST, Dão Gottwald [:dao]
no flags Details | Diff | Splinter Review
possible styles (18.19 KB, image/png)
2007-01-30 07:54 PST, Dão Gottwald [:dao]
no flags Details
WIP extension: No more transformation on focus or mouseover (6.40 KB, application/x-xpinstall)
2007-01-31 04:29 PST, Dão Gottwald [:dao]
no flags Details
updated WIP extension (6.55 KB, application/x-xpinstall)
2007-02-01 04:11 PST, Dão Gottwald [:dao]
no flags Details
new approach (extension) (8.62 KB, application/x-xpinstall)
2007-02-12 19:05 PST, Dão Gottwald [:dao]
no flags Details
some fixes, tested on Windows only (8.75 KB, application/x-xpinstall)
2007-02-13 03:18 PST, Dão Gottwald [:dao]
no flags Details
some fixes, tested on Windows only (8.76 KB, application/x-xpinstall)
2007-02-13 03:37 PST, Dão Gottwald [:dao]
no flags Details
mousedown behaviour fixed (8.73 KB, application/x-xpinstall)
2007-02-13 03:50 PST, Dão Gottwald [:dao]
no flags Details
drag&drop fixed (9.16 KB, application/x-xpinstall)
2007-02-13 08:27 PST, Dão Gottwald [:dao]
no flags Details
auto-complete fixed (9.16 KB, application/x-xpinstall)
2007-02-13 14:42 PST, Dão Gottwald [:dao]
no flags Details
workaround for selection flashing (9.17 KB, application/x-xpinstall)
2007-02-13 15:09 PST, Dão Gottwald [:dao]
mbeltzner: ui‑review-
Details
WIP (10.03 KB, application/x-xpinstall)
2007-02-14 05:29 PST, Dão Gottwald [:dao]
no flags Details
0.6.5 (10.29 KB, application/x-xpinstall)
2007-02-14 09:16 PST, Dão Gottwald [:dao]
no flags Details
0.7 (10.85 KB, application/x-xpinstall)
2007-02-14 17:48 PST, Dão Gottwald [:dao]
no flags Details
0.7.1 (10.86 KB, application/x-xpinstall)
2007-02-15 15:54 PST, Dão Gottwald [:dao]
no flags Details
0.7.2 (11.18 KB, application/x-xpinstall)
2007-02-15 20:31 PST, Dão Gottwald [:dao]
no flags Details
0.7.2.1 (11.17 KB, application/x-xpinstall)
2007-02-16 05:24 PST, Dão Gottwald [:dao]
no flags Details
0.7.3 (11.25 KB, application/x-xpinstall)
2007-02-17 09:10 PST, Dão Gottwald [:dao]
no flags Details
0.7.3.1 (11.30 KB, application/x-xpinstall)
2007-02-17 17:25 PST, Dão Gottwald [:dao]
no flags Details
0.8 (8.86 KB, application/x-xpinstall)
2007-02-18 08:00 PST, Dão Gottwald [:dao]
no flags Details
Breaks IRI on RTL Host/TLD and path (34.77 KB, image/png)
2007-02-18 10:30 PST, Behnam Esfahbod [:zwnj]
no flags Details
0.8.1 (9.76 KB, application/x-xpinstall)
2007-02-18 15:51 PST, Dão Gottwald [:dao]
no flags Details
possible styles (4.91 KB, image/png)
2007-02-18 17:01 PST, Dão Gottwald [:dao]
no flags Details
0.8.2 (9.84 KB, application/x-xpinstall)
2007-02-19 08:48 PST, Dão Gottwald [:dao]
no flags Details
0.8.2.1 (10.02 KB, application/x-xpinstall)
2007-02-19 18:48 PST, Dão Gottwald [:dao]
no flags Details
0.8.2.2 (9.92 KB, application/x-xpinstall)
2007-02-20 04:33 PST, Dão Gottwald [:dao]
no flags Details
0.8.3 (14.40 KB, application/x-xpinstall)
2007-02-21 09:52 PST, Dão Gottwald [:dao]
no flags Details
0.8.5.1 (19.76 KB, application/x-xpinstall)
2007-02-25 04:47 PST, Dão Gottwald [:dao]
no flags Details
secure site UI (127.35 KB, image/png)
2007-03-15 14:04 PDT, Dão Gottwald [:dao]
no flags Details
1.0a1 (30.97 KB, application/x-xpinstall)
2007-03-15 16:11 PDT, Dão Gottwald [:dao]
no flags Details
alternative secure site UI (organization on the left) (127.34 KB, image/png)
2007-03-15 16:22 PDT, Dão Gottwald [:dao]
no flags Details
1.0a2 (31.19 KB, application/x-xpinstall)
2007-03-16 17:47 PDT, Dão Gottwald [:dao]
no flags Details
0.9.0.3 for UI review (7.77 KB, application/x-xpinstall)
2007-04-03 11:37 PDT, Dão Gottwald [:dao]
no flags Details
0.9.0.4: No hidden protocols, all gray but eTLD+2, fully encoded Unicode URLs (7.36 KB, application/x-xpinstall)
2007-05-21 06:45 PDT, Dão Gottwald [:dao]
no flags Details
patch v1 (30.21 KB, patch)
2007-05-23 16:49 PDT, Dão Gottwald [:dao]
no flags Details | Diff | Splinter Review
patch v2 (30.20 KB, patch)
2007-05-24 00:24 PDT, Dão Gottwald [:dao]
no flags Details | Diff | Splinter Review
patch v3 (30.82 KB, patch)
2007-05-26 01:23 PDT, Dão Gottwald [:dao]
no flags Details | Diff | Splinter Review
patch v4 (32.41 KB, patch)
2007-05-26 14:41 PDT, Dão Gottwald [:dao]
no flags Details | Diff | Splinter Review
patch v5 (35.99 KB, patch)
2007-05-28 14:30 PDT, Dão Gottwald [:dao]
no flags Details | Diff | Splinter Review
patch v6 (34.53 KB, patch)
2007-06-05 14:00 PDT, Dão Gottwald [:dao]
gavin.sharp: review-
mbeltzner: ui‑review+
Details | Diff | Splinter Review
patch v7 (31.44 KB, patch)
2007-06-26 06:30 PDT, Dão Gottwald [:dao]
no flags Details | Diff | Splinter Review
patch v7.1 (30.47 KB, patch)
2007-06-26 07:05 PDT, Dão Gottwald [:dao]
no flags Details | Diff | Splinter Review
patch v7.2 (30.51 KB, patch)
2007-06-26 07:13 PDT, Dão Gottwald [:dao]
no flags Details | Diff | Splinter Review
patch v7.3 (32.63 KB, patch)
2007-06-26 07:19 PDT, Dão Gottwald [:dao]
no flags Details | Diff | Splinter Review
patch v7.4 (32.48 KB, patch)
2007-06-26 07:49 PDT, Dão Gottwald [:dao]
gavin.sharp: review+
Details | Diff | Splinter Review
patch for checkin (32.66 KB, patch)
2007-06-26 14:42 PDT, Dão Gottwald [:dao]
no flags Details | Diff | Splinter Review
follow-up (3.77 KB, patch)
2007-06-27 00:41 PDT, Dão Gottwald [:dao]
gavin.sharp: review+
Details | Diff | Splinter Review
patch v8 (37.08 KB, patch)
2007-06-27 05:44 PDT, Dão Gottwald [:dao]
no flags Details | Diff | Splinter Review
enable binding, disable effective domain detection (4.15 KB, patch)
2007-06-30 15:36 PDT, Dão Gottwald [:dao]
no flags Details | Diff | Splinter Review
enable binding, disable effective domain detection (2.37 KB, patch)
2007-06-30 15:45 PDT, Dão Gottwald [:dao]
gavin.sharp: review+
Details | Diff | Splinter Review

Description Dão Gottwald [:dao] 2007-01-12 02:45:31 PST
From <http://wiki.mozilla.org/Firefox/Feature_Brainstorming:Addressbar>:

> When nonlatin characters are used in address they are urlencoded.
> Many sites use them. Wikipedia is an example. But URL shown in an
> addressbar gets totally unreadable, like
> http://uk.wikipedia.org/wiki/%D0%92%D1%96%D0%BA%D1%96%D0%BF%D0%B5%D0%B4%D1%96%D1%8F.
> 
> Such URL is not an easy thing write down on paper for example. It would
> be nice if such URLs were shown more like this (the non-latin part could be
> highlighted or formatted to prevent phishing):
> http://uk.wikipedia.org/wiki/Вікіпедія

And:

> Make the domain name within the URL bold or otherwise highlighted to reduce
> the spoofing risks of complex URLs.

Based on those suggestions, I've created the "Locationbar²" extension:
http://en.design-noir.de/mozilla/locationbar2/

I tried to keep it simple (no fancy colors like some users requested) and make it useful for both novices and experienced users. Besides some early bugs that are fixed now, I got only positive responses (avg. rating on AMO is 5.0). Thus I'm asking if such an enhancement could make it into, say, Firefox 3.
Comment 1 Dão Gottwald [:dao] 2007-01-12 03:56:32 PST
I think what backs it up best is this AMO comment:

> First time I downloaded this extension I found it useless.
> 1 week after I installed I had to format my PC, after that I installed Firefox
> and missed something. Guess what? This extension.
> Believe me, this extension helps a lot. Not just for me, for my father too.


Note that the extension works differently on trunk and 1.8 branches. It tries to use Effective TLD Service <http://wiki.mozilla.org/Gecko:Effective_TLD_Service> and then makes only the main domain bold, otherwise the entire hostname.
Comment 2 Dão Gottwald [:dao] 2007-01-14 16:31:42 PST
Created attachment 251477 [details] [diff] [review]
patch

Since at least nobody disagreed actively, here's my first try.

I'm not sure if toolkit is the right place for the new binding, and if browser.css is the right place for assigning it to #urlbar.

I was going to ask Simon Bünzli for a first review, but apparently he's not available.

Regarding UI review: I guess you can also use the extension for that, it looks the same. Plus it has a preferences UI, so you could easily test what would be good default values.
Comment 3 Dão Gottwald [:dao] 2007-01-14 16:37:03 PST
Comment on attachment 251477 [details] [diff] [review]
patch

Err, I wonder what that means:

>+++ base/content/browser.js	14 Jan 2007 23:44:13 -0000
>@@ -1,4 +1,4 @@
>-# -*- Mode: Java; tab-width: 2; indent-tabs-mode: nil; c-basic-offset: 2 -*-
>+# -*- Mode: Java; tab-width: 2; indent-tabs-mode: nil; c-basic-offset: 2 -*-
Comment 4 Mike Connor [:mconnor] 2007-01-15 10:19:22 PST
I've been running with the latest version of this for a few days, I'm not sure I like the interaction, visually its interesting, but trying to click into a URL is jarring and frustrating.  Let's not jump ahead too fast here, though I think it shows promise.
Comment 5 Dão Gottwald [:dao] 2007-01-15 11:38:22 PST
(In reply to comment #4)
> trying to click into a URL is jarring and frustrating.

It's a price I was willing to pay after some hours. It slightly changed the way I click into URLs (i.e. set the focus first, then look for the target position) and now I hardly notice a difference. Also, I expect that editing URLs partly is not a common task for the average user.
Nevertheless, it's certainly not optimal, and if someone could come up with one or two fresh ideas, that would be great.
Comment 6 Alex 2007-01-16 11:27:37 PST
Assuming this is incorporated into Firefox 3, when editing the URL manually can it be coded so you can edit the bold type (i.e.- without making the URL bar revert to normal when focused; keep the domain bold if opted)? That would make it easier to edit instead of having to focus onto the URL bar.
Comment 7 Dão Gottwald [:dao] 2007-01-16 14:40:58 PST
(In reply to comment #6)
You couldn't copy the original URL then. That's pretty bad.
Comment 8 Dão Gottwald [:dao] 2007-01-16 16:54:48 PST
Created attachment 251704 [details] [diff] [review]
patch 2

some code cleanup, adding browser.urlbar.decode

I've picked gavin and beltzner randomly; feel free to change the review requests.

An unrelated note: I feel that "gapingSpaces" is bad English, but didn't have a better idea ... maybe "innerSpaces"?
Comment 9 Mike Beltzner [:beltzner, not reading bugmail] 2007-01-16 17:51:08 PST
Comment on attachment 251704 [details] [diff] [review]
patch 2

I liked this more than I thought I would. While not an overly radical simplification of the URL field, I think it works rather well. 

I'm not sure that this is ready to land on trunk yet. Some quick suggestions, more to come (and potentially a blog post!)

 - use "separator spaces" instead of "gaping spaces"

 - when restoring the full URI for editing, we should put the cursor where they clicked so the interaction is seamless

 - I wonder if it might be worth exploring an option to truncate the path portion to fit in the location bar, so we'd see:

O mozilla.org /projects/.../filename.html
Comment 10 Dão Gottwald [:dao] 2007-01-16 18:46:22 PST
(In reply to comment #9)
>  - I wonder if it might be worth exploring an option to truncate the path
> portion to fit in the location bar, so we'd see:
> 
> O mozilla.org /projects/.../filename.html

I think that's a counter-example, because the removed portion is at least as interesting as the filename.
Comment 11 Dão Gottwald [:dao] 2007-01-17 02:33:37 PST
(In reply to comment #9)
>  - when restoring the full URI for editing, we should put the cursor where they
> clicked so the interaction is seamless

I tried to save the cursor position (this.inputField.selectionStart), but that's 0 when you click on the domain node (html:strong). I guess you would have to replace urlbar's <html:input/> with <xul:editor/> in order to solve this, but I'm not sure.
I could also save the pointer position of the click event. Would it be possible to emulate a new click afterwards?
Any other ideas?

Note that this only affects Unix (browser.urlbar.clickSelectsAll = false).
Comment 12 Dão Gottwald [:dao] 2007-01-17 04:40:23 PST
Created attachment 251766 [details] [diff] [review]
WIP 3

notes:

  - Using a dirty timeout, because click is dispatched way after focus.

  - Click doesn't reach the event listener at all if you click on the text,
    which rattens the whole approach.

  - Disable "strong domain" in order to see how it should work. Even that
    is suboptimal, because the characters have different widths.

synced extension: http://design-noir.de/mozilla/locationbar2/0.3.7.2.xpi
Comment 13 Dão Gottwald [:dao] 2007-01-17 05:26:42 PST
>   - Click doesn't reach the event listener at all if you click on the text

... because the target node doesn't exist anymore after plainView()
Comment 14 Dão Gottwald [:dao] 2007-01-17 06:23:54 PST
Created attachment 251785 [details] [diff] [review]
WIP 4

>   - Using a dirty timeout, because click is dispatched way after focus.

ugly hack removed, although the click event is still late (I would expect that it's dispatched *before* focus.)

>   - Click doesn't reach the event listener at all if you click on the text,
>     which rattens the whole approach.

fixed

>   - Disable "strong domain" in order to see how it should work. Even that
>     is suboptimal, because the characters have different widths.

fixed

synced extension: http://design-noir.de/mozilla/locationbar2/0.3.7.3.xpi
Comment 15 Dão Gottwald [:dao] 2007-01-17 06:29:05 PST
Created attachment 251787 [details] [diff] [review]
WIP 4 (had typo)
Comment 16 Dão Gottwald [:dao] 2007-01-17 06:37:12 PST
Now there's a bug if the location bar didn't have focus and you start selecting.
Comment 17 Dão Gottwald [:dao] 2007-01-17 06:47:49 PST
Oh, and Ald+D / F6 are broken.
Comment 18 Dão Gottwald [:dao] 2007-01-17 06:49:32 PST
Alt+D
Comment 19 Dão Gottwald [:dao] 2007-01-17 10:38:21 PST
Comment on attachment 251787 [details] [diff] [review]
WIP 4 (had typo)

I suppose that will perform better with the mousedown event.
Comment 20 Dão Gottwald [:dao] 2007-01-17 16:28:27 PST
Created attachment 251846 [details] [diff] [review]
patch 5

synced extension: http://design-noir.de/mozilla/locationbar2/0.3.7.4.xpi
Comment 21 Dão Gottwald [:dao] 2007-01-17 16:42:38 PST
I probably misunderstood comment 4, because I had clickSelectsAll set to true. Anyway, that should now be fixed or at least not _that_ frustrating.
Comment 22 Dão Gottwald [:dao] 2007-01-18 07:27:18 PST
Created attachment 251930 [details] [diff] [review]
patch 6

moving from themes to xul.css
Comment 23 Dão Gottwald [:dao] 2007-01-18 07:32:37 PST
Created attachment 251931 [details] [diff] [review]
patch 6

diff was broken
Comment 24 Dão Gottwald [:dao] 2007-01-18 09:22:40 PST
Comment on attachment 251931 [details] [diff] [review]
patch 6

>+        this.inputField.addEventListener("mousemove", function(event) {
>+          if (self._focused && select) {
>+            var selectionEnd = self._getCursorPosition(event);
>+            if (selectionStart < selectionEnd)
>+              this.setSelectionRange (selectionStart, selectionEnd);
>+            else
>+              this.setSelectionRange (selectionEnd, selectionStart);
>+          }
>+        }, false);

While this feels just like normal selecting on my Windows builds (both trunk and branch), it's rather sluggish Firefox 2 / Ubuntu. I wonder if that's better on trunk.
Comment 25 jasir 2007-01-18 12:59:14 PST
small, simple, sweet, superb!

if i'm not asking too much, may be an option to hide the long unimportant parts of urls that continue after .php, .cgi, etc. That's not required for a normal user. Ofcourse you may make it optional.

for eg,
http://mail.google.com/mail/?zx=t3o2avjrs3vu&auth=DQAAAHgAAADYGfSxNd....
may be simplified as:
mail.google.com /mail/~

or something ending like:
http://abc.com/index.php?crumb=huJG5Ruh9qP....
or https://addons.mozilla.org/search.php?app=firefox&type=E&appfilter=fi...
may be reduced to
abc.com /indiex.php~ and addons.mozilla.org /search.php?~

Also, many be shorten long urls with lots of "/"s to something like:
www.abc.com /files/~/ page1.html

where ~ is used to denote that a portion is hidden.
Comment 26 Mike Beltzner [:beltzner, not reading bugmail] 2007-01-18 13:35:06 PST
It's certainly maintaining some form of cursor position when I click now, but it seems to not be taking into account the offset of restoring the protocol string (http://, https://) and so I'm a little off to the side of where I expect to be. 

Other than that it seems to work well!
Comment 27 Dão Gottwald [:dao] 2007-01-18 14:03:42 PST
(In reply to comment #25)
I don't like both suggestions (see comment 10 for one reason), but I could implement them.

What should be considered as well is to make this extensible in a clean way, i.e. not expecting developers to overwrite prettyView().

(In reply to comment #26)
Currently, it places the cursor wherever your mouse pointer is. Subtracting the width of the protocol would be easy. But with the strong domain, the spaces and the decoded part, it would remain a moving target.
Comment 28 jasir 2007-01-18 14:39:20 PST
(In reply to comment #27)
I understand.
But then why not giveita try? 
Make them optional features?

Comment 29 Dão Gottwald [:dao] 2007-01-18 20:32:15 PST
(In reply to comment #26)
> It's certainly maintaining some form of cursor position when I click now, but
> it seems to not be taking into account the offset of restoring the protocol
> string (http://, https://) and so I'm a little off to the side of where I
> expect to be.

Another idea: what about switching to the plain view on mouseover? That would also fix the performance issue (comment 24).


(In reply to comment #28)
> I understand.
> But then why not giveita try?

Maybe later, I'd like to fix real showstoppers first (but it's not my decision anyway).
Comment 30 Dão Gottwald [:dao] 2007-01-19 07:11:12 PST
Created attachment 252056 [details] [diff] [review]
patch 7, using mouseover

http://design-noir.de/mozilla/locationbar2/0.4.xpi
Comment 31 Dão Gottwald [:dao] 2007-01-20 01:59:55 PST
Created attachment 252149 [details] [diff] [review]
patch 7, cleaned up

no behaviour change
Comment 32 Dão Gottwald [:dao] 2007-01-20 02:15:36 PST
username:password@ is always removed from URLs before the location bar gets them, isn't it? In that case I'll remove the corresponding part.

btw, in order to test that, I opened
data:text/html;,<a href="http://anonymous:anonymous@mozilla.com">x</a>

The patched location bar thinks, data:text/html;,<a href="http:// would be the protocol and mozilla.com">x< the host ... I'll have to update the URL parser regexp.
Or is there a service I could utilize?
Comment 33 Dão Gottwald [:dao] 2007-01-20 05:45:23 PST
Created attachment 252155 [details] [diff] [review]
patch 8, using the location object

see comment 32
Comment 34 Dão Gottwald [:dao] 2007-01-20 05:48:12 PST
-> http://design-noir.de/mozilla/locationbar2/0.4.1.xpi
Comment 35 Dão Gottwald [:dao] 2007-01-20 05:53:44 PST
Created attachment 252156 [details] [diff] [review]
real patch 8

was flawed
Comment 36 Daniel Veditz [:dveditz] 2007-01-20 11:27:49 PST
(In reply to comment #32)
> I'll have to update the URL parser regexp.
> Or is there a service I could utilize?

You should use nsIURI instead of the location element (e.g. gBrowser.currentURI instead of gBrowser.contentDocument.location). nsIURI::scheme will always be exactly what the network engine interprets as the scheme.

I was going to suggest you should also be using currentURI.asciiHost to get the punycoded version of the hostname (can't get that from location) on the assumption the EffectiveTLD service requires it. It does specify using stringprep (rfc 3454) but not full IDN and even says UTF-8 is used in the file.

That's a bit confusing. over in the bug to hook up dom storage to the TLD service dcamp used asciiHost, but maybe that's not going to work. I think UTF-8 is a mistake, the effectiveTLD list should be punycode (true ascii). Otherwise we have to keep editing the effective TLD list in accordance with our list of IDN-enabled domains, but the IDN domain list is really easy for users (or local partners) to edit

Load the following:
IDN-enabled:  http://gäb.de/   vs  http://xn--gb-via.de/  --> both gäb
Not IDN:      http://gäb.com/  vs  http://xn--gb-via.com/ --> both xn--gb-via

On the other hand for your purposes you do want to show the IDN name if the browser's going to show it, so nsIURI.host might be OK.

we can argue asciiHost vs host elsewhere, but either way you should do all your URI parsing through nsIURI rather than string operations.
Comment 37 Dão Gottwald [:dao] 2007-01-20 17:10:30 PST
Created attachment 252188 [details] [diff] [review]
patch 9, nsIURI instead of location

no real UI change, hence no extension update for now
Comment 38 jasir 2007-01-21 01:50:35 PST
(In reply to comment #37)
> Created an attachment (id=252188) [details]
> patch 9, nsIURI instead of location
> 
> no real UI change, hence no extension update for now
> 

check out this extension (split browser)
it handles the location bar part pretty well.

https://addons.mozilla.org/firefox/4287/
Comment 39 Dão Gottwald [:dao] 2007-01-21 07:51:06 PST
split browser duplicates the location bar. seems unrelated to this bug.
Comment 40 Dão Gottwald [:dao] 2007-01-21 08:06:22 PST
Comment on attachment 252188 [details] [diff] [review]
patch 9, nsIURI instead of location

>+            if (valid && gBrowser.userTypedValue) {
>+              try {
>+                var uri2 = Components.classes["@mozilla.org/network/standard-url;1"].createInstance(Components.interfaces.nsIURI);
>+                uri2.spec = this._value;
>+                valid = (uri.spec == gURIFixup.createExposableURI(uri2).spec);
>+              } catch(e) {}
>+            }

I'm doing this in order to check if the location bar value matches currentURI. Is there a cleaner way to achieve this?
Options I see are:

 1. reset userTypedValue when submitting, so that I could replace the quoted
    chunk with |if (valid) valid = !gBrowser.userTypedValue|.

 2. don't use currentURI but always create a mew nsIURI object for the
    current location bar value.

 3. ignore userTypedValue in prettyView(), i.e. only show the maybe-typed
    value on mouseover or focus.
Comment 41 :Gavin Sharp [email: gavin@gavinsharp.com] 2007-01-21 14:36:30 PST
I haven't really read the patch yet, so I don't know the answer to your question, but I just wanted to point out that you should never createInstance an nsIURI, unless you're implementing a protocol handler. The IOService has a newURI method that you should use, see http://developer.mozilla.org/en/docs/Common_Pitfalls#How_to_create_a_URI_object . There's also an nsIURI equals() method that you can use if you want to compare two nsIURI objects for equality (rather than comparing .spec), though I'm not sure whether it applies here.
Comment 42 Dão Gottwald [:dao] 2007-01-21 14:44:11 PST
(In reply to comment #41)
> you should never createInstance an nsIURI, unless you're implementing a
> protocol handler. The IOService has a newURI method that you should use

Thanks, I'll take care of that.

> There's also an nsIURI equals() method that you can use if you want to
> compare two nsIURI objects for equality (rather than comparing .spec), though
> I'm not sure whether it applies here.

I tried that first, didn't seem to work. Anyway, I want to avoid such a comparison.
Comment 43 Dão Gottwald [:dao] 2007-01-21 15:45:36 PST
Created attachment 252265 [details] [diff] [review]
patch 10

kind of implements point 2 of comment 40 and uses IOService (comment 41)
Comment 44 Daniel Veditz [:dveditz] 2007-01-21 20:52:03 PST
(In reply to comment #36)
> That's a bit confusing. over in the bug to hook up dom storage to the TLD
> service dcamp used asciiHost, but maybe that's not going to work. I think UTF-8
> is a mistake, the effectiveTLD list should be punycode (true ascii). Otherwise
> we have to keep editing the effective TLD list in accordance with our list of
> IDN-enabled domains, but the IDN domain list is really easy for users (or local
> partners) to edit

Turns out the effectiveTLD service takes the UTF-8 list and normalizes it on load. Having the data pre-normalized might save a smidgen of time for any non-ascii domains but is not necessary, and having the .dat file more readable is a win.

You also don't have to give the service punycode, it'll take IDN and normalize it before comparing to the domain list. But the "number of characters" answer will be based on the normalized string so the answer might not match the string you have if yours is not already normalized. A bit confusing, all the more reason for the string-returning helper methods I proposed.
Comment 45 Simon Bünzli 2007-01-22 04:15:57 PST
A few things to think about, should this indeed be the way to go:

> Index: browser/app/profile/firefox.js
> +pref("browser.urlbar.decode", true);

Who'd want to toggle this pref? Since this is mostly for aesthetic reasons, we might be able to do without it and just always decode the URLs.

> +pref("browser.urlbar.strongDomain", true);
> +pref("browser.urlbar.separatorSpaces", 2);

These two prefs are purely presentational and should thus be replaced with CSS rules. Those users who actually care will still be able to adjust the appearance through userChrome.css.

> Index: browser/base/content/browser.js
> +var gDecodeURLs = false;

Don't use global variables, if you can do without. In this case, either get the values directly from the prefs where you assign them below - or even better, get the values in the constructor of the new binding. What clickSelectsAll does, doesn't really scale that nicely.

> Index: content/widgets/urlbar.xml
> +      <field name="alwaysPlainSchemes">["about","data"]</field>

Couldn't this be replaced with a check for whether a domain/host name is defined for a specific URI instead? Otherwise mailto: and possibly a few other protocols would also belong into this category.

> +              var uri = gBrowser.currentURI;

gBrowser (and gURIFixup) is Firefox- and not Toolkit-specific. You'll either have to do without it - or move the binding from toolkit to browser.

> +      <handler event="mouseover" phase="capturing"
> +               action="if (!this._plain) this.plainView();"/>

You should probably store the mouse-over state somewhere. Otherwise refreshing the page through F5/Ctrl+R will require a mouse-out before you can edit the address (there won't be another mouseover event even when the mouse is moved within the address bar).
Comment 46 Dão Gottwald [:dao] 2007-01-22 04:42:07 PST
(In reply to comment #45)
> > +pref("browser.urlbar.strongDomain", true);
> > +pref("browser.urlbar.separatorSpaces", 2);
> 
> These two prefs are purely presentational and should thus be replaced with CSS
> rules. Those users who actually care will still be able to adjust the
> appearance through userChrome.css.

But those style rules wouldn't apply to the content of the input element. Maybe I should put the nodes directly into the chrome and hide the input element. 

> > Index: content/widgets/urlbar.xml
> > +      <field name="alwaysPlainSchemes">["about","data"]</field>
> 
> Couldn't this be replaced with a check for whether a domain/host name is
> defined for a specific URI instead? Otherwise mailto: and possibly a few other
> protocols would also belong into this category.

file URIs don't have a host, but I do want to decode them and strip off file://
Hm. But I think in about:config, host is undefined, and in file:///foo, it's empty, so that could be a solution.
Comment 47 :Gavin Sharp [email: gavin@gavinsharp.com] 2007-01-22 05:53:43 PST
The new urlbar binding should probably be added in /browser and not /toolkit, since it's pretty browser-specific and not really reusable for most other toolkit apps. That also avoids the dependency issues Simon mentions.
Comment 48 Dão Gottwald [:dao] 2007-01-22 09:42:40 PST
I thought it could be useful for apps like Songbird.
Comment 49 :Gavin Sharp [email: gavin@gavinsharp.com] 2007-01-22 10:14:15 PST
I'm not sure that "could be useful" is significant enough to justify putting this into toolkit at the moment. It's easy to move into toolkit if there's a demonstrated need by other consumers, but it's nearly impossible to remove it from toolkit once it's been added for fear of breaking people who may depend on it, so I'd prefer defaulting to putting it in /browser.
Comment 50 Daniel Veditz [:dveditz] 2007-01-22 11:06:40 PST
What about SeaMonkey? They're trying hard to get their trunk version based on toolkit (but not /browser). How could they not want this? I guess we could ask, and put it in /browser if they show no interest.
Comment 51 Benjamin Smedberg AWAY UNTIL 2-AUG-2016 [:bsmedberg] 2007-01-22 11:11:32 PST
I agree this should be app-specific code. SM/songbird/whoever can reuse through copying if necessary.
Comment 52 Dão Gottwald [:dao] 2007-01-22 17:14:46 PST
Created attachment 252406 [details] [diff] [review]
WIP 11

- handled all points in comment 45
- moved to /browser, but removed the dependencies (global variables)
- added a fading effect

known issues:
- long URLs overflow the location bar (I'm not sure how to fix this)
Comment 53 Dão Gottwald [:dao] 2007-01-23 04:11:23 PST
Created attachment 252451 [details] [diff] [review]
patch 12

http://design-noir.de/mozilla/locationbar2/0.5.xpi (slightly modified for Firefox 2)
Comment 54 Dão Gottwald [:dao] 2007-01-23 04:45:48 PST
Created attachment 252456 [details] [diff] [review]
patch 12

just a small fix, extension updated as well (same URL)

Maybe fading on mouseover won't work. If you click really fast, the cursor (for some reason) will be put at the end of the location bar. I could speed it up (takes 110 milliseconds currently), but theoretically, it would always be possible to click faster.
Comment 55 Simon Bünzli 2007-01-23 11:58:23 PST
Comment on attachment 252456 [details] [diff] [review]
patch 12

Please wait for ui-review first, this isn't the time for a close-up review yet. And then rather ask a browser peer, I don't have much more to contribute.
Comment 56 Dão Gottwald [:dao] 2007-01-23 12:29:08 PST
Wasn't meant as a final review request.
Comment 57 Rod Begbie 2007-01-24 12:02:15 PST
With the 0.5.xpi on Firefox 2, I'm seeing the bug that if I focus on the address-bar by hitting ALT+D, URL autocompletion doesn't work, although it does if I focus on the address-bar by clicking.
Comment 58 Dão Gottwald [:dao] 2007-01-25 07:08:01 PST
Created attachment 252774 [details] [diff] [review]
patch 13

some cleanup

added an extra element to the binding, because overflow:hidden interfered with -moz-box-align:center, which caused problems with many themes.
Comment 59 Dão Gottwald [:dao] 2007-01-25 07:11:40 PST
(In reply to comment #58)
> Created an attachment (id=252774) [details]
> patch 13

http://design-noir.de/mozilla/locationbar2/0.5.1.xpi

(In reply to comment #57)
> With the 0.5.xpi on Firefox 2, I'm seeing the bug that if I focus on the
> address-bar by hitting ALT+D, URL autocompletion doesn't work, although it does
> if I focus on the address-bar by clicking.

Yeah, but I don't know why. Any suggestions would be appreciated.
Comment 60 Dão Gottwald [:dao] 2007-01-25 16:25:23 PST
text-overflow:ellipsis would be nice, wouldn't it?
Comment 61 Mike Beltzner [:beltzner, not reading bugmail] 2007-01-25 19:06:07 PST
(In reply to comment #59)
 > (In reply to comment #57)
> > With the 0.5.xpi on Firefox 2, I'm seeing the bug that if I focus on the
> > address-bar by hitting ALT+D, URL autocompletion doesn't work, although it does
> > if I focus on the address-bar by clicking.
> 
> Yeah, but I don't know why. Any suggestions would be appreciated.

It also doesn't seem to be consistent. I see it sometimes, but not all.
Comment 62 Dão Gottwald [:dao] 2007-01-26 08:14:29 PST
Created attachment 252919 [details] [diff] [review]
patch 14

- crops long URLs
- new pref: browser.urlbar.animateBlend
- more code cleanup

autocomplete is still broken.

http://design-noir.de/mozilla/locationbar2/0.5.2.xpi
Comment 63 Dão Gottwald [:dao] 2007-01-27 01:45:16 PST
Created attachment 253007 [details] [diff] [review]
patch 15

autocomplete should be working again

http://design-noir.de/mozilla/locationbar2/0.5.3.xpi
Comment 64 Dão Gottwald [:dao] 2007-01-27 02:46:42 PST
color:graytext could be used, e.g. for the port.
Let me know if that's wanted.
Comment 65 Dão Gottwald [:dao] 2007-01-28 08:28:51 PST
Comment on attachment 253007 [details] [diff] [review]
patch 15

>+          try {
>+            // UTF-8
>+            path = decodeURIComponent(path);
>+          } catch(e) {
>+            // ISO Latin
>+            path = unescape(path);
>+          }

I'll probably remove the ISO Latin part, since it could be any encoding in reality.
Comment 66 Gervase Markham [:gerv] 2007-01-30 04:03:24 PST
I've been using Locationbar2, and think it has some really neat ideas. However, I think we also need some discussion about how to make it more usable, particularly in the selection scenario. I'm also concerned that making domain names bold can actually decrease readability - it certainly reduces the difference, on my copy of Firefox, between "i" and "l". 

However, I'm not sure that this bug is the best place to do feature development. Dao: would you care to suggest a better forum?

Gerv
Comment 67 Dão Gottwald [:dao] 2007-01-30 06:04:47 PST
Beltzner wrote he would potentially blog about this. Maybe it's also something for Mozilla Labs? They could point to a wiki page, which is probably the best place for collecting ideas.
Comment 68 Dão Gottwald [:dao] 2007-01-30 07:54:19 PST
Created attachment 253336 [details]
possible styles

I could also imagine using a smooth shadow for the domain (bug 10713).
Comment 69 Gervase Markham [:gerv] 2007-01-30 09:28:59 PST
Dao: we need to find some way of having the position of the letters not jump when you focus the control - otherwise it gets really annoying. 

This means that whatever highlighting we pick, it needs to stay when the control is focussed. Are there technical reasons why that is difficult?

Gerv
Comment 70 Robert Kaiser 2007-01-30 09:40:53 PST
I still feel a bit nervous about hiding the protocol. I don't think FTP/HTTP/HTTPS differences are unimportant enough to hide them (by default).
Comment 71 Dão Gottwald [:dao] 2007-01-30 11:37:12 PST
(In reply to comment #69)
> This means that whatever highlighting we pick, it needs to stay when the
> control is focussed. Are there technical reasons why that is difficult?

In the earlier versions, I was hacking the input field's editor object, with the result that the content wasn't fully editable anymore. I guess I could use Midas instead, but then styling the content wouldn't be as easy as it is now (i.e. through browser.css, userChrome.css etc.).

(In reply to comment #70)
> I still feel a bit nervous about hiding the protocol. I don't think
> FTP/HTTP/HTTPS differences are unimportant enough to hide them (by default).

FTP isn't hidden by default and secure sites are indicated in other (better) ways.
Comment 72 Robert Kaiser 2007-01-30 11:57:34 PST
Dão:
What are "better" ways? Coloring of the bar and an icon on a completely different part of the window are nice, but the latter is not too visible for many people and the coloring easily gets lost on other themes and/or low-color schemes. Additionally, there are lots of advisories out there that tell "make sure the display in the location bar starts with https://" - but maybe I'm just too nervous about it. I hope there's some pref for it we can default to off when maybe proting this to SeaMonkey browser one time - or we'll invent that ourselves ;-)
Comment 73 Dão Gottwald [:dao] 2007-01-30 12:04:50 PST
"make sure the display in the location bar starts with https://" isn't a good advice, since it doesn't mean that there's a valid certificate.
Comment 74 Unknown W. Brackets 2007-01-30 12:52:00 PST
(In reply to comment #73)
> "make sure the display in the location bar starts with https://" isn't a good
> advice, since it doesn't mean that there's a valid certificate.
> 

Bad advice doesn't mean uncommon advise.  Quite the opposite.  Just because sites and companies shouldn't tell people that doesn't mean they don't.

Example: go to eBay.  They say, I quote, right on the login page:

"Be sure the Web site address you see above starts with https://signin.ebay.com/"

My grandma really is going to listen to that before remembering some yellowish color that supposedly means something or other.  Is it really worth the evangelism to hide the protocol, which has been shown everywhere for years and no longer scares anyone (that I know of)?

Just my opinion.  I personally really like the idea of bolding the domain, but other than that it seems over the top.

-[Unknown]
Comment 75 Caio Tiago Oliveira (asrail) 2007-01-30 13:08:17 PST
The "low color" condition is very, very important.

One of the most important accessibility features is that we shouldn't rely on color alone to transmit information.

Some people can't see the difference between white and light yellow (there are a lot of other color combinations, I met people who see the world white, black, brown and purple).
The ones who have to use low-color schemes won't even notice it (both are gray here, same color, I wouldn't be able to know about the protocol except for the *little* icon at the very botom at the left of the screen).

In case of visual defficience, that little icon wouldn't make any difference, anyway.


In inverse high contrast I'm seing a little difference in the status bar (the border color), but that is not easily noticed. In high contrast the only difference is the border width (it's hard to guess by its size is it is a http or https site).


I'm strongly against hiding http, https or whatever.

Comment 76 Caio Tiago Oliveira (asrail) 2007-01-30 13:16:36 PST
Another great issue is that I wouldn't be able to copy'n'past links from SM into a lot of programs.

Some programs don't treat example.site.org as a link, while treat http://example.site.org (or http://whatever) as a link.
These programs/services usually treat www.site.org as a link, but not site.org or foo.site.org, because the lack of the space after the dot does not means it's a URL (it might be a typo).
Local URLs might consist of a word. So "localhost" is not a URL, while "http://localhost" is one.

I always use the http:// part while composing messages, so I'll be sure that it will be linkified for almos everyone.


I would be happy if I could copy links from the location bar with http:// before it.

Ah... no JS here, please, because it's good to have the option to choose if you will copy the http part or not without depending on a preference (I meant I should be able to copy only the "localhost" part to a message, if I'm chating with the sys-admin or...).

Comment 77 Dão Gottwald [:dao] 2007-01-30 13:59:44 PST
If you feel that the lock isn't good enough as an indicator, you should file a new bug for that. "https://" is not good enough, but contrary the the real "secure site" UI it won't enhance. Besides the fact that it's too cryptic, it can be a false friend. It's worthless as a visual metaphor.

(In reply to comment #74)
> Is it really worth the
> evangelism to hide the protocol, which has been shown everywhere for years and
> no longer scares anyone (that I know of)?

The lock has been there for years as well, across browsers. And at the end of the day, they really want to say "Be sure the Web site's domain name is ebay.com". Currently they can't do that, because users would have to parse the URL.

(In reply to comment #76)
Copy & paste is not an issue. Feel free to install Firefox and try the extension.
Comment 78 Daniel Veditz [:dveditz] 2007-01-30 14:09:51 PST
(In reply to comment #73)
> "make sure the display in the location bar starts with https://" isn't a good
> advice, since it doesn't mean that there's a valid certificate.

If an https page loaded then the certificate was valid (including cases where the user has said "I know better, this is valid"). We're planning to make the user-override case harder, btw.

Comment 79 Gervase Markham [:gerv] 2007-01-30 14:41:26 PST
I am for hiding the scheme. IMO, the differences between FTP and HTTP are incomprehensible to the average web user. In the HTTPS case, if we are telling people to look for the difference between the strings "http" and "https" in the UI in order to gain useful information, then our UI sucks rocks and we should fix it.

Removing the scheme allows us to do things like display an HTTPS site whose certificate has expired but is otherwise valid as if it was served over HTTP - which I think is a very good way of dealing with that particular error condition - without causing mixed signals.

As for copy and paste, we could (for example) prepend the scheme to a copied selection if that selection extends to the left edge of the URL bar.

Gerv
Comment 80 Chris Thomas (CTho) [formerly cst@andrew.cmu.edu cst@yecc.com] 2007-01-30 15:33:48 PST
(In reply to comment #77)
> If you feel that the lock isn't good enough as an indicator, you should file a
> new bug for that. "https://" is not good enough, but contrary the the real
> "secure site" UI it won't enhance. Besides the fact that it's too cryptic, it
> can be a false friend. It's worthless as a visual metaphor.
> 
> (In reply to comment #74)
> > Is it really worth the
> > evangelism to hide the protocol, which has been shown everywhere for years and
> > no longer scares anyone (that I know of)?
> 
> The lock has been there for years as well, across browsers. And at the end of
> the day, they really want to say "Be sure the Web site's domain name is
> ebay.com". Currently they can't do that, because users would have to parse the
> URL.

Maybe I'm just an idiot, but for *years* I wondered wtf an oil can was doing in the Netscape 3+ status bar: http://images.google.com/images?q=oil%20can
Comment 81 Dão Gottwald [:dao] 2007-01-30 18:16:38 PST
Comment on attachment 253007 [details] [diff] [review]
patch 15

working on a new patch
Comment 82 Dão Gottwald [:dao] 2007-01-31 04:29:12 PST
Created attachment 253467 [details]
WIP extension: No more transformation on focus or mouseover

This has some limitations, mainly because I'm using <xul:editor/> that has to act like <html:input/>. Most notably, F6, right-click actions and auto-complete don't work yet. Would be nice if someone could take a look at the code and give me some hints.
Comment 83 Dão Gottwald [:dao] 2007-02-01 02:50:50 PST
How can <editor/> be made transparent?
Comment 84 Gervase Markham [:gerv] 2007-02-01 03:18:33 PST
You're asking in the wrong place :-) Try the newsgroups.

FWIW, I've had to disable Locationbar2 after installing your update. You broke Ctrl-L and focus, and it got very irritating very quickly. But please, do persist :-) Why not ask some of our core XUL hackers whether you are using the right approach?

Gerv
Comment 85 Dão Gottwald [:dao] 2007-02-01 04:11:46 PST
Created attachment 253597 [details]
updated WIP extension

This doesn't really solve the problems. Just in case someone is willing to investigate, this might be a slightly better starting point.
Comment 86 Dão Gottwald [:dao] 2007-02-01 07:21:23 PST
Comment on attachment 253007 [details] [diff] [review]
patch 15

I've posted to mozilla.dev.tech.xul in order to get some hints. However, I'm not sure if this will lead anywhere; you might want to review that fairly stable version anyway.
Comment 87 Dão Gottwald [:dao] 2007-02-12 15:51:20 PST
a user comment from my website:

> is there any chance of making it act similar to the vista address bar.
> So while hovering on the address bar but not having clicked it, make it so u can
> select part of the URL to navigate to there?
> If you wanted to edit the url you would click on the white space at then end
> This would be handy from time to time.

Again, let me know if that's wanted. Maybe I'll give it a try anyway, although I don't know the "vista address bar".


btw, I didn't get a response in dev.tech.xul.
Comment 88 Caio Tiago Oliveira (asrail) 2007-02-12 17:27:29 PST
Instead of:
C:\Users\[user]\Documents\Links

you see:
[a picture] -> Documents -> Links

where those arrows are dropdown menus that list the contents of the folder.
When you mouse over the items they become clickable.

If you click the icon at the left or some white-space it changes to the traditional way (C:\Users...).

The user might be confused about where to click (or what to do) to be able to select the URL.

Well... I had a idea...

the users that don't like the mouse would still being able to select it with Control+L (that would trigger the very traditional way)...
the most users could get a "copy url" or "copy [protocol]:[the url]" and "copy [protocol]:[[optional prefix] domain]" to the clipboard, instead of selecting it and using Control+C or right-click and selecting "copy".

I may try to do a little HTML example (I don't know XUL very well) if someone desires.

VMWare lets me create movies... I could make a little one showing the way it works, although I don't like some things there.
Or I could make some screenshots.
Comment 89 Dão Gottwald [:dao] 2007-02-12 17:49:02 PST
Thanks, but I'm already implementing it. Looks good so far. Selecting all with Ctrl+L or when clicking the site icon already worked out of the box. I don't know how "copy url", "copy [protocol]:[the url]" etc. should work; maybe you can elaborate on that later.

I don't think we want a Vista rip-off, so you don't need to make a video either.
Comment 90 Dão Gottwald [:dao] 2007-02-12 19:05:26 PST
Created attachment 254902 [details]
new approach (extension)

see comment 87
Comment 91 Caio Tiago Oliveira (asrail) 2007-02-12 20:59:00 PST
On Windows: when you click some link the URL bar switches to the normal mode-view, gots selected, then it loads the link. It's very quick, you might even don't notice depending on the time it takes to load the page, but the URL bar flashing is annoying.

On Linux: the above behaviour doesn't exist, but it won't switch to the normal mode-view while clicking with the mouse in any non-linkified portion of the URL-bar.


Just to mention: I've chat with Dão about to respect the "open link" settings and to allow to use middle or control+click and he told this could be left to a follow up bug.

Comment 92 Dão Gottwald [:dao] 2007-02-13 03:18:30 PST
Created attachment 254932 [details]
some fixes, tested on Windows only

(In reply to comment #91)
> On Windows: when you click some link the URL bar switches to the normal
> mode-view, gots selected, then it loads the link.

fixed

> Just to mention: I've chat with Dão about to respect the "open link" settings
> and to allow to use middle or control+click and he told this could be left to a
> follow up bug.

fixed

> On Linux: the above behaviour doesn't exist, but it won't switch to the normal
> mode-view while clicking with the mouse in any non-linkified portion of the
> URL-bar.

I still don't have access to Linux (right now) or OS X (at all) ...
Comment 93 Dão Gottwald [:dao] 2007-02-13 03:37:50 PST
Created attachment 254933 [details]
some fixes, tested on Windows only

just a quick update, right-click was broken.
Comment 94 Dão Gottwald [:dao] 2007-02-13 03:45:18 PST
(In reply to comment #93)
> just a quick update, right-click was broken.

and the left mouse button breaks the urlbar when "mousedown" fires but "click" doesn't, i.e. when moving the mouse away after "mousedown".
Comment 95 Dão Gottwald [:dao] 2007-02-13 03:50:14 PST
Created attachment 254935 [details]
mousedown behaviour fixed

see last comment
Comment 96 Caio Tiago Oliveira (asrail) 2007-02-13 07:40:30 PST
Right click and middle click are OK on Linux, but what I told about Linux on comment 91 still valid.

I'll test to see if it's related to some accessibility thing later, or if it's general to Linux.
Comment 97 Dão Gottwald [:dao] 2007-02-13 07:51:20 PST
The old autocomplete bug is back. It works with Ctrl+L, but not when clicking into the urlbar. Apparently attachController() doesn't work when the input field's opacity is less than 1. It's annoying ...
Comment 98 Dão Gottwald [:dao] 2007-02-13 08:27:53 PST
Created attachment 254951 [details]
drag&drop fixed
Comment 99 Dão Gottwald [:dao] 2007-02-13 08:30:53 PST
I don't know what to do about the auto-complete bug. It works after removing this rule:

#urlbar:not([plain="true"]) .textbox-input-box {
  opacity: 0;
}
Comment 100 :Gavin Sharp [email: gavin@gavinsharp.com] 2007-02-13 08:33:40 PST
Why are you setting opacity to 0?
Comment 101 Dão Gottwald [:dao] 2007-02-13 08:36:36 PST
I'm using <stack> instead of <deck> in order to make the input field accessible even if it's not visible.
Comment 102 Dão Gottwald [:dao] 2007-02-13 14:42:59 PST
Created attachment 254999 [details]
auto-complete fixed

color: transparent; does the trick
Comment 103 Dão Gottwald [:dao] 2007-02-13 14:54:13 PST
(In reply to comment #92)
> (In reply to comment #91)
> > On Windows: when you click some link the URL bar switches to the normal
> > mode-view, gots selected, then it loads the link.
> 
> fixed

this regressed, probably because the selection is visible now (it wasn't when the opacity was 0).
Comment 104 Dão Gottwald [:dao] 2007-02-13 15:09:33 PST
Created attachment 255009 [details]
workaround for selection flashing

added:

#urlbar:not([plain="true"]) {
  -moz-user-select: none;
}

I have a dream that one day I won't discover yet another problem immediately after hitting "Submit".
Comment 105 Dão Gottwald [:dao] 2007-02-13 17:01:47 PST
(In reply to comment #102)
> color: transparent; does the trick

only on trunk
Comment 106 Mike Beltzner [:beltzner, not reading bugmail] 2007-02-13 21:20:23 PST
Comment on attachment 255009 [details]
workaround for selection flashing

I know I've been withholding comment for a while. I had to wait on a conversation about where we want to feature this, and how we want to play with it. Basically, here's where we stand:

- I think this is a really interesting experiment, and when labs gets up and running, I want to feature it there to get more feedback from the world at large

- landing *all* of this on trunk without a clear definition of what the problems users currently have with the location bar seems inappropriate to me, and we're going to run afoul of reactionary arguments as to why this isn't actually helping things (more on that below)

- I'm not going to grant this ui-r until it's ready for inclusion on the trunk, so I'd suggest you hold off on the request until we've iterated around on this some more.

- we should probably track progress in this bug, still, but soon there will be a place at labs.mozilla.com where we can discuss design in a little more detail
Comment 107 Mike Beltzner [:beltzner, not reading bugmail] 2007-02-13 21:27:09 PST
Bah, I forgot to fill out the "below" part from comment 106 :)

LocationBar^2 originally was meant to fulfill the requests from the Firefox 3 brainstorming wiki (as mentioned in comment 0). It's done that, and more! The things requested on the brainstorming page were clear problems:

 - the location bar didn't display non-latin characters properly
 - the domain name was lost within the entire URL, showing the domain (or just the TLD and root domain) in bold would help reduce the effectiveness of homonym phishing attacks

These things are clear problems, and a patch that addresses just those things (but doesn't remove the protocol prefix or screw with direct edit, etc) would get a ui-r+ from me for trunk.

Since that original set of problems, we've gone off into some really interesting experiments, including:

 - stripping the somewhat hard to understand protocol prefix
 - separating the domain information from the path information
 - segmenting the path information and turning each segment into a link

These aren't directly linked to reported problems, and are creative solutions and enhancements. As experiments, I think we should encourage people to try them and comment, but until we figure out whether or not they're solving real user problems, they're not suitable for inclusion into the mainline product.

I hope this makes sense; I want to balance the Right Thing for the Product with Being Creative and Exploring New Ideas. :)
Comment 108 Mike Beltzner [:beltzner, not reading bugmail] 2007-02-13 21:44:57 PST
And my last comment of the evening will be on the experimental changes to the location bar with some UI feedback :)

= Vista-esque Location Bar =

(In reply to comment #89)
> Thanks, but I'm already implementing it. Looks good so far. Selecting all with
> Ctrl+L or when clicking the site icon already worked out of the box. I don't
> know how "copy url", "copy [protocol]:[the url]" etc. should work; maybe you
> can elaborate on that later.

Ugh, ick and ugh again. Removing the ability to directly edit the URI takes a *lot* of power away. I can no longer, for example, quickly replace part of the URI, or copy a segment of the URI, or do many of the actions that I'm used to doing. The reason this works in the Vista File Explorer is that they can make each segment a drop-down that's populated with the other directories at that level - so you can get all the power of manual edit while using the mouse. That isn't possible on the web, though, since we have no index of the entire directory structure of a site (though invoking history from that point would be interesting!)

Part of the success of this feature will be adding usefulness while not taking away usefulness, and I think this mod fails in that respect. For the first time in weeks I've been forced to disable the extension, as I'm simply unable to work as quickly with it.

Let's think about the problem we're trying to solve here, and then think about solutions for getting us there. Or figure out ways of adding the functionality without removing the old interactions. For example, if when you hover over a segment of the path a little (->) arrow appeared and clicking on that would use that segment as a link, otherwise click would select, drag would edit, etc, etc. 

= Stripping the protocol =

I think this is largely good, but we need to make sure that the semantics indicated by the protocol are preserved and visible to the user. For example, SSL semantics are also communicated by the colour of the location bar and the padlock icon. But what of the semantics of file:// and ftp://? The former seems important, the latter is debatable, but something should be added so that users can still get that information about their location context, especially in the case where they're browsing the local drive.

= Adding spaces between path segments =

This makes the URI harder to read, actually, since now every element (domain and path) has the same visual spacing. I think it's easier to segment domain from path with a single space between the two elements.

= Other things we could do =

We should think about how people use the location bar. Evidence shows that users do a lot of "type-in" URLs, and advanced users modify URIs to navigate sites they're familiar with. Other common actions are:

 - return to root of site
 - back / forward
 - next / previous page (increment/decrement some value in the URI)
 - go to a page within this domain that I've been to before (combination of direct-edit the URI and pull selection from history)
 - fix a typo in the URI
 - replace entire URI with a new URI (ie: navigate elsewhere on the web)

What can we do to support these specific use cases? Here are some ideas:

 - the domain element could have a widget that goes back to the root of the domain
 - right-click on any segment of the path could truncate the URI to that point and offer selections from history drop down
 - a single selection widget for clearing the location bar and jumping to a new point
 - right click on a numeric value could offer increment/decrement values expressed as "next" / "previous"
Comment 109 Dão Gottwald [:dao] 2007-02-14 05:09:25 PST
(In reply to comment #107)
> Since that original set of problems, we've gone off into some really
> interesting experiments, including:
> 
>  - stripping the somewhat hard to understand protocol prefix
>  - separating the domain information from the path information
>  - segmenting the path information and turning each segment into a link
> 
> These aren't directly linked to reported problems, and are creative solutions
> and enhancements.

The first and the second points are closely linked to "the domain name was lost within the entire URL".

> As experiments, I think we should encourage people to try
> them and comment, but until we figure out whether or not they're solving real
> user problems, they're not suitable for inclusion into the mainline product.
> 
> I hope this makes sense; I want to balance the Right Thing for the Product with
> Being Creative and Exploring New Ideas. :)

Sure; I'm looking forward to the Labs feedback.

(In reply to comment #108)
> Ugh, ick and ugh again. Removing the ability to directly edit the URI takes a
> *lot* of power away. I can no longer, for example, quickly replace part of the
> URI, or copy a segment of the URI, or do many of the actions that I'm used to
> doing. [...]
> Part of the success of this feature will be adding usefulness while not taking
> away usefulness, and I think this mod fails in that respect.

With version 0.5, I worked around this by switching to the plain view on mouseover. I can't do that anymore, because of the new interactivity of the formatted view. Maybe the selecting behaviour can be tweaked, but I don't think it will eventually be equal to the legacy textbox, unless somebody comes up with a totally new idea.

> = Stripping the protocol =
> 
> I think this is largely good, but we need to make sure that the semantics
> indicated by the protocol are preserved and visible to the user. For example,
> SSL semantics are also communicated by the colour of the location bar and the
> padlock icon. But what of the semantics of file:// and ftp://?

the visible difference between file and http is that there's no hostname for file. ftp isn't removed currently.
Comment 110 Dão Gottwald [:dao] 2007-02-14 05:11:16 PST
oh, and:

> Here are some ideas:
> 
>  - the domain element could have a widget that goes back to the root of the
> domain

that's already the case since the domain is a link.
Comment 111 Dão Gottwald [:dao] 2007-02-14 05:29:14 PST
Created attachment 255084 [details]
WIP

addresses the following points:

> For example, if when you hover over a
> segment of the path a little (->) arrow appeared and clicking on that would use
> that segment as a link, otherwise click would select, drag would edit, etc,
> etc.

  Drag doesn't works, since the location bar would have to be in "plain" mode
  before mousedown fires.


> = Adding spaces between path segments =
> 
> This makes the URI harder to read, actually, since now every element (domain
> and path) has the same visual spacing. I think it's easier to segment domain
> from path with a single space between the two elements.

  I still gave the slashes inside of the path a padding of 1px.

>  - right-click on any segment of the path could truncate the URI to that point

  I think it's better to select all and provide a context menu for right-click.
  Hence I've used left-click, but not on the segments but on the slashes.


Firefox 2 isn't supported anymore (-> comment 105).
Comment 112 Gervase Markham [:gerv] 2007-02-14 05:34:17 PST
Dao: I agree with Mike; this is a great experiment, but we'll need to play around a lot to figure out exactly which of the changes we want to take on the trunk. And that would be made a lot easier if we could turn each one on and off individually, to try out different combinations.

Do you think you might be able to do a pref panel to allow that? I realise it's a non-trivial amount of work.

Gerv
Comment 113 Mike Connor [:mconnor] 2007-02-14 05:37:29 PST
I don't think that's useful at all.  About:config prefs _maybe_, but let's not encourage people to waste time on building UI for experimental features...
Comment 114 Gervase Markham [:gerv] 2007-02-14 05:46:26 PST
about:config prefs would be fine, if a pref panel is considered to be unnecessary effort. I care about the configurability much more than the mechanism (as long as it's not hand-editing CSS files in the extensions directory :-).

The prefs may or may not be part of any checkin which results from this experimentation: I just think it's useful to have them while we are deciding which of the changes we want to take.

Gerv
Comment 115 Dão Gottwald [:dao] 2007-02-14 05:53:41 PST
Actually, adding a UI would be trivial, as soon as the prefs are functional ;)
But adding prefs is relatively hard, as the code is not that modular.
Comment 116 Mike Connor [:mconnor] 2007-02-14 06:32:15 PST
1) We should be able to do something with favicon-like creatures to indicate a local file and/or ftp.  Neither really supports favicons so this should be universally possible.  I'll note that the treatment of ftp:// is ok as a fallback, but not as good as stripping the scheme entirely, since I think its not well understood or useful to present in addition to other things.

2) I actually find this behaviour really useful, since most of my URL editing is essentially going up a level or three.  Would like to be able to directly highlight chunks of the URL and change/edit them.  Maybe highlight the current text (using the same logic as we use in content to handle the selection of links), and convert that to a selection of the plaintext on mouseup?  Its slightly different when editing the middle of URLs, but without having a pretty comprehensive set of use cases to walk through in my head, but I think its a compromise that still allows "Up" navigation in the pseudo-breadcrumb approach here.

I think that most of the improvements we can make for users who don't understand URLs will impact power user manipulation of URLs to some extent.  Where we want to balance those needs is going to be fun.
Comment 117 Gervase Markham [:gerv] 2007-02-14 07:40:58 PST
Using favicons to indicate local files might run a risk that a website can pretend to be a local directory by spoofing the favicon. I don't know if that's a risk or not.

I think that the difference between ftp:// and http:// is now entirely irrelevant to the average Internet user, and would become even more so if we actually styled FTP listings nicely. So I second the proposal to get rid of ftp://.

As for selection, why don't we make the URL bar work like other text, where single click places the cursor, double-click selects a "word" (or URL component, in this case) and triple-click selects the whole thing?

Admittedly without evidence, I assert that the average user's interactions with the URL bar involves only typing something new to replace what's there already. Hacking bits off the end of URLs or modifying URL parameters is real power-user stuff, and I don't see that changing even if we make the divisions in a URL more obvious.

Gerv
Comment 118 Dão Gottwald [:dao] 2007-02-14 07:49:04 PST
regarding ftp see bug 294800. my proposal for that bug also includes a favicon: http://design-noir.de/bugzilla/ftp/ftp.xhtml
Comment 119 Mike Beltzner [:beltzner, not reading bugmail] 2007-02-14 08:02:21 PST
(In reply to comment #111 and others)
> the visible difference between file and http is that there's no hostname for
> file. ftp isn't removed currently.

Maybe we want to insert a "Your Computer" string at the root and a favicon to
represent it. Just to make it clear that's where the user is browsing.

> I still gave the slashes inside of the path a padding of 1px.

I don't think that's strictly neccessary, but I'm looking forward to seeing
what it's like. I can't install it on my copy of Minefield right now because it
isn't packaged to support 3.0a3pre :(

> But adding prefs is relatively hard, as the code is not that modular.

Yeah, I don't think we really need to do that, as long as we can get to a point
where there are various versions of the patch that people can try and comment
on with the different ideas exposed. Like, right now, I can install a version
from any point in the design by clicking on that XPI in the attachment list -
that's good enough for me, really. :)

(In reply to comment #116)
> I think that most of the improvements we can make for users who don't
> understand URLs will impact power user manipulation of URLs to some extent. 
> Where we want to balance those needs is going to be fun.

I agree, and so far what we have is a UI that replaces three types of
functionality:

 - selection (for copy/paste)
 - direct edit
 - quick invoke of typeahead find at a single segment of the URI

with:

 - ability to link directly to a portion of the URI, breadcrumb style

What mconnor suggests about using the same sort of logic as we use in the
content area for highlighting text in links makes sense to me. We should also
switch the mouse icon to a finger, since right now it makes no sense to be an
i-beam.

Again, I'd really love to see a patch for trunk that does the first two things
from comment 107, and then continued experimentation for the other things we're
all talking about.
Comment 120 Caio Tiago Oliveira (asrail) 2007-02-14 08:33:14 PST
(In reply to comment #119)
> (In reply to comment #111 and others)
> > the visible difference between file and http is that there's no hostname for
> > file. ftp isn't removed currently.
> 
> Maybe we want to insert a "Your Computer" string at the root and a favicon to
> represent it. Just to make it clear that's where the user is browsing.

That's a wonderfull idea.

> > I still gave the slashes inside of the path a padding of 1px.
> 
> I don't think that's strictly neccessary, but I'm looking forward to seeing
> what it's like. I can't install it on my copy of Minefield right now because it
> isn't packaged to support 3.0a3pre :(

The last one attachment installs on 3a3pre. It won't install on 3a2pre, indeed. It says it supports from 3a2 to 3a3 and I've tested with 3a3pre (from day 12th).

I don't think them look ugly, 1px is not a great ammount.

Comment 121 Dão Gottwald [:dao] 2007-02-14 09:16:44 PST
Created attachment 255115 [details]
0.6.5

- clicking a segment selects it
- ftp:// hidden
- added a conditional hack for Gecko 1.8 (namely opacity:0 instead of color:transparent, which means that auto-complete remains broken with Firefox 2)
Comment 122 Dão Gottwald [:dao] 2007-02-14 09:33:51 PST
I'm starting to lose track ... we really need a wiki for all the suggestions.

(In reply to comment #116)
> We should also
> switch the mouse icon to a finger, since right now it makes no sense to be an
> i-beam.

The current logic is as follows:

- cursor:pointer if clicking will lead to a new page
- cursor:default if clicking will truncate but not submit the value
- cursor:text if the value won't be modified, but only selected

> Again, I'd really love to see a patch for trunk that does the first two things
> from comment 107, and then continued experimentation for the other things we're
> all talking about.

Like http://design-noir.de/mozilla/locationbar2/0.5.4.1.xpi? Or does that already go too far?
Comment 123 Dão Gottwald [:dao] 2007-02-14 17:48:19 PST
Created attachment 255164 [details]
0.7

Here comes the "Your Computer" prefix for file URIs (no i18n yet).
I also did some refactoring and fixed several small bugs, and Gecko 1.8 compatibility should be better (my quirky detection failed occasionally).
Comment 124 Caio Tiago Oliveira (asrail) 2007-02-14 19:22:36 PST
Why can't I go to the root of my filesystem?
I think it would make sense to have that arrow with a shortcut to the root of the filesystem.

Comment 125 Dão Gottwald [:dao] 2007-02-14 20:03:57 PST
That would have to be platform-specific; Windows doesn't have a root directory.
Comment 126 Caio Tiago Oliveira (asrail) 2007-02-14 21:33:28 PST
I can confirm:
> On Linux: the above behaviour doesn't exist, but it won't switch to the normal
> mode-view while clicking with the mouse

on Ubuntu Dapper, a clean install. I also confirm after removing the package at-spi (I've though this one could be accessibility related).

Just one change:
sometimes (it's random) when I click some portion it becomes selected, but I still without the focus on the URL bar and the pretty view still appearing (the selection and the text of the plain URL override it).


PS: I'm almost get it working on SM done... after this I could do some more tests and even could try to fix it.
Comment 127 Caio Tiago Oliveira (asrail) 2007-02-14 21:50:19 PST
(In reply to comment #125)
> That would have to be platform-specific; Windows doesn't have a root directory.
> 

file://C:/foo/bar
against
file:///foo/bar

could have something like
   Your computer/root/foo/bar
when you have a slash at the start of the file URL.


> PS: I'm almost get it working on SM done... after this I could do some more
> tests and even could try to fix it.
On Suiterunner... I'm too lazy to make a install.js.

Comment 128 Dão Gottwald [:dao] 2007-02-15 09:16:31 PST
(In reply to comment #127)
> file://C:/foo/bar
> against
> file:///foo/bar
> 
> could have something like
>    Your computer/root/foo/bar
> when you have a slash at the start of the file URL.

nope, it's file:///C:/...
Comment 129 Gervase Markham [:gerv] 2007-02-15 10:29:45 PST
Those CCed on this bug may be interested in:
http://weblogs.mozillazine.org/gerv/archives/2007/02/location_bar_proposal.html
and associated newsgroup posting in mozilla.dev.apps.firefox.

Gerv
Comment 130 Behnam Esfahbod [:zwnj] 2007-02-15 13:48:58 PST
I was working on a similar extension, to remove the uri-schema from the address field, to make it able to be align:Right and dir:RTL.  In fact, IRI just forces to show the internationalize *URI* in LTR base direction.  So by removing the schema from the address field, we can make set the align/dir of the field based on UILocale or field's content (ie. making a list of RTL TLDs...).

Then another issue is how to show the protocol.  I used to add a dropdown-like widget to the address-bar (mine was before the site icon) with a localizable user-friendly text, like "Web" for http, and "File Transfer" for ftp.  I think we really need someway to show the protocol, as there are a lot of hosts which support both http and ftp on the same address, and have completely different content for each protocol.

Thanks for the good job. :)
Comment 131 Dão Gottwald [:dao] 2007-02-15 15:54:47 PST
Created attachment 255274 [details]
0.7.1

Some users meant that 0.7 is actually less usable than 0.6. I understand the problem they have, but I don't want to go back. Instead I've replaced all the slashes by permanent, little Go buttons. New: middle-clicking a segment truncates the URL and opens the auto-complete popup.

Finally, all this should work with Firefox 2.
Comment 132 Dão Gottwald [:dao] 2007-02-15 15:56:22 PST
(In reply to comment #124)
> Why can't I go to the root of my filesystem?

should work now
Comment 133 Dão Gottwald [:dao] 2007-02-15 20:31:18 PST
Created attachment 255301 [details]
0.7.2

This should fix the problems with Linux (thanks Asrail!). I've also updated the skin.
Comment 134 Torben 2007-02-16 01:41:44 PST
> I think that the difference between ftp:// and http:// is now entirely
> irrelevant to the average Internet user, and would become even more so if we
> actually styled FTP listings nicely. So I second the proposal to get rid of
> ftp://.

But how do I easily switch from ftp://ftp.example.com to http://ftp.example.com ? There are a lot of sites where these are _not_ the same.
Comment 135 Dão Gottwald [:dao] 2007-02-16 03:11:16 PST
(In reply to comment #134)
> But how do I easily switch from ftp://ftp.example.com to http://ftp.example.com
> ? There are a lot of sites where these are _not_ the same.

e.g. Ctrl+L, Home, Ctrl+Del, Enter
Comment 136 Dão Gottwald [:dao] 2007-02-16 04:59:59 PST
(In reply to comment #121)
> - clicking a segment selects it

I have to take care of clickSelectsAll=false
Comment 137 Dão Gottwald [:dao] 2007-02-16 05:24:07 PST
Created attachment 255331 [details]
0.7.2.1

see previous comment
Comment 138 Nickolay_Ponomarev 2007-02-16 06:46:34 PST
Double-clicking to select parts of the URL on windows may not work properly now that the contents of the URL bar is changed (formatting stripped) on click. (This applies to the URL parameters only, like ?id=XXX on bugzilla, since to select other parts of the URL, it's enough to single click it.

Great job otherwise.
Comment 139 Jason Barnabe (np) 2007-02-16 14:18:27 PST
Can we drop the trailing triangle when we're at the root of the domain?
Comment 140 Dão Gottwald [:dao] 2007-02-16 14:52:45 PST
(In reply to comment #139)
> Can we drop the trailing triangle when we're at the root of the domain?

Technically, yes:

.textbox-presentation-prePath:not([can-submit="true"]) > .segment-submit {
  display: none;
}
Comment 141 Dão Gottwald [:dao] 2007-02-17 09:10:48 PST
Created attachment 255456 [details]
0.7.3

As a result of Gerv's proposal and the related discussion in mozilla.dev.apps.firefox, this version does:

  1. remove the path segments' arrows
  2. remove the "Your Computer" label for file:// URIs
  3. display HDD letters as the domain for Windows file URIs
  4. drop the emphasis for IDN domains

I've also revised the mouse actions:

> left                          | select segment
> ------------------------------|-----------------------------------------
> Ctrl/Cmd + left,              | truncate URL after segment
> middle                        |
> ------------------------------|-----------------------------------------
> Alt/Option + left             | navigate to truncated URL
> ------------------------------|-----------------------------------------
> Alt/Option + Ctrl/Cmd + left, | open truncated URL in new tab
> Alt/Option + middle           |
> ------------------------------|-----------------------------------------
> Alt/Option + Shift + left     | open truncated URL in new window
> ------------------------------|-----------------------------------------
> Shift + left                  | select all (Win)
> ------------------------------|-----------------------------------------
> right                         | select all (Win), open the context menu


Still, not all of this seems to work with Linux, and I don't have a clue if it does with OS X. If you can, please test it on Windows in order to get a sane impression of the concept.
Comment 142 Caio Tiago Oliveira (asrail) 2007-02-17 10:03:58 PST
Alt + left will, by default on most Linux window managers, move the window, so the event is not propagated to Firefox. I believe changing the default shortcut for this would help.

Alt + Control + left works, for instance, but Alt + Shift + left arrives to the same issue as above.


"select all" works on Linux, as well as selecting a token when clicking it if browser.urlbar.clickSelectsAll is true at the startup (it would be good to change this behaviour, but it's the same without the extension, so it's a FX issue, not yours). I do believe it's the same for Windows, only the default that changes.

I think the only real issue with Linux is that with a right click it opens the chrome context menu, instead of the URL bar one (I got "navigation toolbar | bookmarks toolbar | customize" instead of "undo | cut | copy | ...").
Take a look.
Comment 143 Dão Gottwald [:dao] 2007-02-17 16:32:54 PST
(In reply to comment #142)
> Alt + left will, by default on most Linux window managers, move the window, so
> the event is not propagated to Firefox. I believe changing the default shortcut
> for this would help.

I'll try Shift. I wanted to avoid that, since Shift is a link target modifier.
Comment 144 Dão Gottwald [:dao] 2007-02-17 17:25:20 PST
Created attachment 255510 [details]
0.7.3.1

Shift instead of Alt, i.e.:

 left                     | select segment
--------------------------|-----------------------------------------
 Ctrl/Cmd + left,         | truncate URL after segment and open
 middle                   | auto-complete popup
--------------------------|-----------------------------------------
 Shift + left             | navigate to truncated URL
--------------------------|-----------------------------------------
 Shift + Ctrl/Cmd + left, | open truncated URL in new tab
 Shift + middle           |
--------------------------|-----------------------------------------
 right                    | select all (Win), open the context menu

(In reply to comment #142)
> I think the only real issue with Linux is that with a right click it opens the
> chrome context menu

fixed

(In reply to comment #139)
> Can we drop the trailing triangle when we're at the root of the domain?

done
Comment 145 Dão Gottwald [:dao] 2007-02-18 08:00:05 PST
Created attachment 255583 [details]
0.8

beltzner, gerv: I think you will like this one.
There are many little changes, but to sum it up: things don't move anymore. On the downside, this means that the protocol isn't hidden (would produce an odd gap otherwise) but only greyed out. Shift still linkifies segments.
Comment 146 Behnam Esfahbod [:zwnj] 2007-02-18 08:58:34 PST
Dão, can't we have hostname bold when entering/editing the url?

Also, there's a funny bug.
- Add boolean key "network.IDN.whitelist.ir" to your prefs
- Open this link: http://xn--mgbbgcw7khi.xn--mgba3a4f16a.ir/
- After page loaded, select the url and press Enter again
- Select the url and press Enter again

You will see punycode and unicode strings periodically!
Comment 147 Behnam Esfahbod [:zwnj] 2007-02-18 09:03:02 PST
And I see URL-Encoded UTF characters instead of unicode characters again, under //xn--mgbbgcw7khi.xn--mgba3a4f16a.ir/ [1], but there's no problem with Persian Wikipedia [2].

[1] http://ثبت‌دامنه.ایران.ir/سلام   (This page doesn't exist)
[2] http://fa.wikipedia.org/wiki/صفحهٔ_اصلی

So I assume there's no pref for this one, and something is related to TLD and/or Host.
Comment 148 Dão Gottwald [:dao] 2007-02-18 10:05:49 PST
(In reply to comment #146)
> Dão, can't we have hostname bold when entering/editing the url?

That will make it less usable again, unless we use a fixed-width font.

> Also, there's a funny bug.
> - Add boolean key "network.IDN.whitelist.ir" to your prefs
> - Open this link: http://xn--mgbbgcw7khi.xn--mgba3a4f16a.ir/
> - After page loaded, select the url and press Enter again
> - Select the url and press Enter again
> 
> You will see punycode and unicode strings periodically!

Funny enough, I see this without the extension.
Comment 149 Gervase Markham [:gerv] 2007-02-18 10:07:17 PST
Dao: you may want to wait until the dust settles on the discussion before doing too much more work. I am not really sure where it'll end up. I've already changed my mind about a couple of things based on what people have said.

I'll certainly try out your new one. But please, be aware that lots of things could change in the future :-) I don't want you to put a load of work in and then feel messed around when they do.

Gerv
Comment 150 Behnam Esfahbod [:zwnj] 2007-02-18 10:30:49 PST
Created attachment 255599 [details]
Breaks IRI on RTL Host/TLD and path

As you can see, when the direction of end-part of hostname, and start of the path are both RTL, current solution breaks IRI.

Trying to fix this problem, you may get a layout problem, which smontagu is working on, which some tags break (bidi) direction runs.

CC: smontagu
Comment 151 Behnam Esfahbod [:zwnj] 2007-02-18 10:34:41 PST
smontagu, would you please take a look at last attachment.
Comment 152 Dão Gottwald [:dao] 2007-02-18 15:51:32 PST
Created attachment 255629 [details]
0.8.1

This contains a fix for IDNs (effective tld service takes them with punycode only).

(In reply to comment #145)
> things don't move anymore. On
> the downside, this means that the protocol isn't hidden (would produce an odd
> gap otherwise)

I worked around this by moving the favicon into that gap. Unideal, but still the best solution that came to my mind. The favicon can be dragged when pressing Shift.

(In reply to comment #149)
> Dao: you may want to wait until the dust settles on the discussion before doing
> too much more work. I am not really sure where it'll end up.

Me neither. It's just, as soon as an idea pops up that is potentially good and probably implementable, I feel the need to try it ;-)
Comment 153 Mike Connor [:mconnor] 2007-02-18 17:01:19 PST
I haven't played with 0.8.1 yet, but I think 0.7.3.1 is the closest I've found to being ok with landing this.  0.8 felt like it was throwing away a lot of useful things...
Comment 154 Dão Gottwald [:dao] 2007-02-18 17:01:24 PST
Created attachment 255638 [details]
possible styles
Comment 155 Dão Gottwald [:dao] 2007-02-19 01:26:58 PST
http://xs412.xs.to/xs412/07081/locationbar.png

Is red an option? I was against it, because it's usually a security-related color. But if all domains are red, it probably doesn't matter. On the other hand, the security-metaphor could be utilized, i.e. a white-list for trusted (green) domains could be added.
Comment 156 Dão Gottwald [:dao] 2007-02-19 01:45:03 PST
(In reply to comment #155)
> i.e. a white-list for trusted (green) domains could be added.

Note that this list could be auto-generated. For example, sites that you have bookmarked or saved passwords for.
Comment 157 Caio Tiago Oliveira (asrail) 2007-02-19 06:51:48 PST
I told some things about relying on color alone for indicating the difference between http/https and Gerv said it is outside the scope of this extension.
But this color would be something added by you, so... please, don't rely on colors alone (see comment 75 as most of that apply to using only color to emphasize the domain).
Comment 158 Dão Gottwald [:dao] 2007-02-19 08:48:30 PST
Created attachment 255693 [details]
0.8.2

- blue text color for domains
- bringing back the gap between domain and path
- spaces re-encoded to %20


(In reply to comment #157)
> please, don't rely on colors alone

Still, a color is better than nothing. So far I don't see alternatives that wouldn't decrease usability.
Comment 159 Jason Barnabe (np) 2007-02-19 09:32:52 PST
Some observations:

I like this much better than 0.7.2 (respecting clickSelectsAll, not having the triangle buttons).

Can you make it so that the URL only changes "views" after pausing on the location bar? I'm finding it somewhat distracting that it's doing its thing when I'm on my way to the search bar.

When you open a new blank tab and start entering a URL, it shouldn't leave a space for a favicon.

Can you make it so that the pieces of text that don't change position don't turn gray for a split-second when you mouse over them?

The text-only view seems to not have enough padding on the left, though this just might be me not being used to it.
Comment 160 Dão Gottwald [:dao] 2007-02-19 13:38:12 PST
(In reply to comment #159)
> Can you make it so that the URL only changes "views" after pausing on the
> location bar? I'm finding it somewhat distracting that it's doing its thing
> when I'm on my way to the search bar.

A delay would mean that the user could click before the input field appears, making it impossible to drag-select.

> Can you make it so that the pieces of text that don't change position don't
> turn gray for a split-second when you mouse over them?

I don't understand what you're seeing there.

> When you open a new blank tab and start entering a URL, it shouldn't leave a
> space for a favicon.
> [...]
> The text-only view seems to not have enough padding on the left, though this
> just might be me not being used to it.

Any space or padding that you add to the editable view has to be added to the formatted view as well.
Comment 161 Jason Barnabe (np) 2007-02-19 13:52:39 PST
(In reply to comment #160)
> > Can you make it so that the pieces of text that don't change position don't
> > turn gray for a split-second when you mouse over them?
> 
> I don't understand what you're seeing there.

Sorry, I meant "when you mouse out". There's a transition that turns the text gray (transparent?) when you go from editable view to formatted view. Since the path part of the URL doesn't change between the views, it'd be better if it didn't transition.

> > When you open a new blank tab and start entering a URL, it shouldn't leave a
> > space for a favicon.
> > [...]
> > The text-only view seems to not have enough padding on the left, though this
> > just might be me not being used to it.
> 
> Any space or padding that you add to the editable view has to be added to the
> formatted view as well.

I understand. But regarding the first, it appears as though new blank tabs have the padding of formatted view even when you're typing in the URL.
Comment 162 Dão Gottwald [:dao] 2007-02-19 15:04:23 PST
(In reply to comment #161)
> Sorry, I meant "when you mouse out". There's a transition that turns the text
> gray (transparent?) when you go from editable view to formatted view. Since the
> path part of the URL doesn't change between the views, it'd be better if it
> didn't transition.

Yes, transparency has a hand in this. The text field's opacity (x) continuously decreases, while the formatted view's opacity (1-x) increases. This works as expected here -- no gray for the parts that keep their position.

> I understand. But regarding the first, it appears as though new blank tabs have
> the padding of formatted view even when you're typing in the URL.

That's because the urlbar doesn't have the "hidden protocol" state there. For example, open chrome://locationbar2/skin/urlbar.css. The input field needs padding for being aligned with the formatted URL. Of course, that doesn't make sense if there's no formatted view anyway. I'll fix that.
Comment 163 Dão Gottwald [:dao] 2007-02-19 18:48:21 PST
Created attachment 255745 [details]
0.8.2.1

-> favicon better reachable (without Shift)

(In reply to comment #161)
> it appears as though new blank tabs have
> the padding of formatted view even when you're typing in the URL.

fixed
Comment 164 Dão Gottwald [:dao] 2007-02-20 04:33:16 PST
Created attachment 255764 [details]
0.8.2.2

- entering the Location bar over the favicon also linkifies segments
  (no need to press Shift)
- more solid behaviour when pressing Shift
Comment 165 Kim Sullivan 2007-02-20 04:58:54 PST
The 0.8.2.1 version breaks some themes - I know it's still a prototype, so I'd like to ask if it's an issue, or if it's not something to worry about yet.
Comment 166 Dão Gottwald [:dao] 2007-02-20 07:28:50 PST
I wouldn't worry about it now as I wouldn't worry about it later. Themes will certainly have to be updated for future Firefox releases -- with or without this bug fixed.
Comment 167 Dão Gottwald [:dao] 2007-02-21 09:52:13 PST
Created attachment 255919 [details]
0.8.3

has some predefined styles to play with
Comment 168 Dão Gottwald [:dao] 2007-02-22 03:51:33 PST
Btw, most of these optional styles cause known problems. So far they're not really there to give new ideas a try but to prove that they don't work. However, the infrastructure for pluggable stylesheets is there. That could be useful for Labs.
Comment 169 Dão Gottwald [:dao] 2007-02-25 04:47:14 PST
Created attachment 256343 [details]
0.8.5.1

significant updates:

- moving the mouse over the Location bar from above linkifies segments
- link targets appear in the status bar
- query string and fragment gray by default (not sure if this is good)
- last directory/file linkified as well (useful for duplicating a tab)
- preferences and pluggable stylesheets updated
Comment 170 Alexey Perepyolkin [:chaos] 2007-02-27 11:09:46 PST
How about to switch to (or from) linkified location bar by pressing key, when location bar is already hovered?

Also it should be nice if location bar default state will be linkified and to edit it we need to right- or middle-clicking on it :)
Comment 171 Dão Gottwald [:dao] 2007-02-27 16:23:20 PST
(In reply to comment #170)
> How about to switch to (or from) linkified location bar by pressing key, when
> location bar is already hovered?

Ctrl is used for copy/paste and Shift for creating selection ranges.

> Also it should be nice if location bar default state will be linkified and to
> edit it we need to right- or middle-clicking on it :)

Drag-selecting doesn't work then. (It could be an option anyway, as mconnor said he would be ok with 0.7.3.1.)
Comment 172 Dão Gottwald [:dao] 2007-02-27 16:37:06 PST
Some summarized thoughts on domain emphasis:

Even beyond accessibility, mixing a certain color (blue) with system colors (-moz-field, -moz-fieldtext) is obviously problematic. It also makes the whole appearance a bit noisy; likewise I'd avoid "highlight" and "highlightText" (attachment 253336 [details], bottom).

Let me repeat that bold is likely a dead end. It's not an option for complex scripts (you could underline IDNs, but still ...), and it's apparently impossible to keep in visual sync with the editable view.

So far the last alternative I see is to use graytext for subdomains. You can mimic this with recent Lb² releases: uncheck domain colors, then visit a site with a "www." subdomain.
Comment 173 Dão Gottwald [:dao] 2007-02-28 08:34:55 PST
As you may have noticed, I'm not adding comments for each release anymore. For those who are interested in the small development steps, here's a feed:
http://en.design-noir.de/mozilla/locationbar2/?versions-feed

If you have suggestions like comment 170, feel free add a comment to my site:
http://en.design-noir.de/mozilla/locationbar2/

This way we should be able to focus the bug on what's most relevant.
Comment 174 Alexey Perepyolkin [:chaos] 2007-02-28 11:59:26 PST
>> How about to switch to (or from) linkified location bar by pressing key, when
>> location bar is already hovered?
>
>Ctrl is used for copy/paste and Shift for creating selection ranges.

I'm not talking about when it is already in focus, but hovered.

>Drag-selecting doesn't work then. (It could be an option anyway, as mconnor
said he would be ok with 0.7.3.1.)

What is drag-selecting? I don't understand the problem.

Is locationbar² to make a revloution in browser's location bars or what? ;-)

Making it configurable will make it more useful.

I think that hovering from top or from bottom to get different behavior is not handy!
Comment 175 Jeff Walden [:Waldo] (remove +bmo to email) 2007-02-28 14:53:25 PST
(In reply to comment #173)
> As you may have noticed, I'm not adding comments for each release anymore.
> [...] This way we should be able to focus the bug on what's most relevant.

Honestly, at this point I don't think that's worthwhile, except as a way of not making people read about every little change you make (which does have some merit, incidentally ;-) ).  This bug has a solid 3-4 screens of attachments, it's up to 175 comments, and when the time comes for real reviews *nobody's* going to want to have to wade through it, so you'll get a new bug filed then anyway.
Comment 176 Dão Gottwald [:dao] 2007-02-28 15:11:28 PST
(In reply to comment #174)
> >> How about to switch to (or from) linkified location bar by pressing key, when
> >> location bar is already hovered?
> >
> >Ctrl is used for copy/paste and Shift for creating selection ranges.
> 
> I'm not talking about when it is already in focus, but hovered.

Umm, yes, I guess that would be possible.
There's of course one problem with these keys: They are used to determine where the URL will be loaded. Hence this isn't a solid replacement for the mouse behavior that you dislike.

> Is locationbar² to make a revloution in browser's location bars or what? ;-)
> 
> Making it configurable will make it more useful.

The default setup is what we have to wrestle with; many users don't really configure anything. If linkification of segments turns out to be a usability problem, one way or another, we shouldn't escape into options, leaving it to the user to make tradeoffs, but just leave this feature out. I suppose most users don't need it. Eventually, a revised Location bar will be extensible again.
Comment 177 Dão Gottwald [:dao] 2007-03-01 03:11:31 PST
http://en.design-noir.de/mozilla/locationbar2/0.8.6.xpi

new prefs: "Gray Subdomains" (comment 172), "Only linkify when pressing Ctrl/Meta or Shift" (somehow comment 176)

(In reply to comment #170)
> How about to switch to (or from) linkified location bar by pressing key, when
> location bar is already hovered?

implemented
Comment 178 Modex 2007-03-01 06:54:39 PST
If you add "Gray Subdomains" can you make linkify only for domains (without of subdomain)?
Comment 179 Gervase Markham [:gerv] 2007-03-05 08:25:51 PST
Dao: I can't get "Gray Subdomains" to be enabled. Even if I remove all colours, it's still greyed out. Any idea what's going on?

Some further thoughts:

- I've written up my latest ideas here:
http://wiki.mozilla.org/Firefox3/Location_Bar

- I love the way that, if you have "placeholder for hidden protocols" and "margin after the host" both checked, only the host moves around and not the rest of the URL. That's so much better. In this case, can you even up the gap on both sides (a tiny nitpick :-)?

- You seem to be greying out the slashes between path components. This seems to me to be exactly the opposite of what you want as an anti-spoofing measure, where separators are very important. Can you make them bold instead?

- Can we have an option to highlight Effective TLD + N, where N is configurable? If not, can we have an option to either do +1 or +2, the two possibilities in question? The non-highlighted part would move around as necessary with the rest of the domain, but would not pick up the colour.

- Any chance of making the highlight colour configurable (#RRGGBB)? I agree bold may not work but, if it doesn't, we need to pick the actual colour carefully.

- I don't know how much control you have over selection behaviour, but can you make it behave like my proposal linked above (section 2.7)?

- Can you outline here your current algorithm for when and how you decode complex URLs in the unfocussed state?

- I like the idea of making the query string a bit lighter, but I think you may have gone too far. Can you darken it a touch more? We need to remember people with poor eyesight.

Thanks :-)

Gerv
Comment 180 Dão Gottwald [:dao] 2007-03-05 18:23:14 PST
(In reply to comment #179)
> Dao: I can't get "Gray Subdomains" to be enabled. Even if I remove all colours,
> it's still greyed out. Any idea what's going on?

Did you use a trunk build? Subdomain detection requires nsEffectiveTLDService, which isn't available (yet) for 1.8.

> - I've written up my latest ideas here:
> http://wiki.mozilla.org/Firefox3/Location_Bar

I'm presumably familiar with most of this already, since I followed the discussion in the newsgroups closely. Anyway, thanks for creating that page. I will take a close look at it.

> - I love the way that, if you have "placeholder for hidden protocols" and
> "margin after the host" both checked, only the host moves around and not the
> rest of the URL. That's so much better. In this case, can you even up the gap
> on both sides (a tiny nitpick :-)?

The gaps will grow if you chose to show the favicon always or never (instead of sometimes.)

> - You seem to be greying out the slashes between path components. This seems to
> me to be exactly the opposite of what you want as an anti-spoofing measure,
> where separators are very important. Can you make them bold instead?

I'm quite sure even a bold slash demands more space, causing the path to move on hover; I'll give it a try, though.

> - Can we have an option to highlight Effective TLD + N, where N is
> configurable? If not, can we have an option to either do +1 or +2, the two
> possibilities in question? The non-highlighted part would move around as
> necessary with the rest of the domain, but would not pick up the colour.

What's the point of TLD + 2? TLD + 1 is the registered domain that you should trust or not trust. You cannot trust yourbank.xxx.com, and users should look at xxx.com first to get that.

> - Any chance of making the highlight colour configurable (#RRGGBB)? I agree
> bold may not work but, if it doesn't, we need to pick the actual colour
> carefully.

I don't think you'll find a color that works significantly better than the blue. Most important, any color can be too close to the default fore- or background color of a random OS theme. So even if it's easy, I wouldn't want to add such a pref; I doubt a non-system color will be the final solution.

> - I don't know how much control you have over selection behaviour, but can you
> make it behave like my proposal linked above (section 2.7)?

I don't have control over the selection behaviour currently, because I hardly touch the input field. But I have that on my radar.

> - Can you outline here your current algorithm for when and how you decode
> complex URLs in the unfocussed state?

decoreURI -- a JS function that decodes Unicode URIs (only) -- is used for both states. However, if you copy the entire value, spaces will be encoded again, which is important for text-based communication with link detection (e-mail, IM, forums ...).

> - I like the idea of making the query string a bit lighter, but I think you may
> have gone too far. Can you darken it a touch more? We need to remember people
> with poor eyesight.

That's "graytext", a system color. I did try to use transparency once, but the result was poor (bug 355972?).
Comment 181 Gervase Markham [:gerv] 2007-03-06 04:49:41 PST
(In reply to comment #180)
> Did you use a trunk build? Subdomain detection requires nsEffectiveTLDService,
> which isn't available (yet) for 1.8.

Oops - that's the problem.

> The gaps will grow if you chose to show the favicon always or never (instead of
> sometimes.)

Sure. I have it set to never, like the proposal. It would be nice for the gap to be even on both sides in this case.

> > - You seem to be greying out the slashes between path components. This seems to
> > me to be exactly the opposite of what you want as an anti-spoofing measure,
> > where separators are very important. Can you make them bold instead?
> 
> I'm quite sure even a bold slash demands more space, causing the path to move
> on hover; I'll give it a try, though.

Give it a try. Otherwise, keep the slashes as #000 black and lighten the path components a bit.

Alternatively, we could have them (and other separators like ?, & and #) bold in both the textbox form and the non-focussed form. I seem to remember you made that possible at one point. But perhaps that had technical issues.

> What's the point of TLD + 2? TLD + 1 is the registered domain that you should
> trust or not trust. You cannot trust yourbank.xxx.com, and users should look at
> xxx.com first to get that.

On the other hand, there are advantages to TLD + 2. For example, consider "gerv.blogspot.com". Also, it means the "www.foo.com", which is a common case, has the www highlighted, which looks nicer.

I agree there are also downsides. The jury is still out on this one - which is why I want it configurable, so we can test both cases.

> > - Any chance of making the highlight colour configurable (#RRGGBB)? I agree
> > bold may not work but, if it doesn't, we need to pick the actual colour
> > carefully.
> 
> I don't think you'll find a color that works significantly better than the
> blue. 

How about a darker blue, for example? I don't know if I'll find a better colour until I can try some :-)

> Most important, any color can be too close to the default fore- or
> background color of a random OS theme. So even if it's easy, I wouldn't want to
> add such a pref; I doubt a non-system color will be the final solution.

Does the Firefox theme we ship by default respect OS colours, then? If not, then this isn't a problem and we won't be using a system colour.

> > - Can you outline here your current algorithm for when and how you decode
> > complex URLs in the unfocussed state?
> 
> decoreURI -- a JS function that decodes Unicode URIs (only) -- is used for both
> states. However, if you copy the entire value, spaces will be encoded again,
> which is important for text-based communication with link detection (e-mail,
> IM, forums ...).

It is allowed to encode spaces as a "+" in URLs, isn't it, as well as %20? Perhaps the textbox version could keep everything encoded, but have spaces as +. That way, there's less jumping between versions than if you had to replace space with %20.

Gerv

Comment 182 Robert Kaiser 2007-03-06 05:42:15 PST
Gerv:
All our default themes try to use OS-style theming, including colors, as much as possible, including the toolkit/Firefox default *stripe theme set.
So if the OS uses dark-blue background on textboxes (with light-yellow text or so), we still should display the location bar properly...
Comment 183 Gervase Markham [:gerv] 2007-03-06 07:53:43 PST
So what system color name will get you the current red, blue and green that the prefs offer? Or are they not system colours?

Is there a list of system colour names and suggested uses somewhere?

Gerv
Comment 184 Dão Gottwald [:dao] 2007-03-06 10:14:51 PST
(In reply to comment #181)
> > The gaps will grow if you chose to show the favicon always or never (instead of
> > sometimes.)
> 
> Sure. I have it set to never, like the proposal. It would be nice for the gap
> to be even on both sides in this case.

I see. That's probably not possible with pure XUL+CSS, at least given how the host is positioned currently. But some scripting should do it.

> Give it a try. Otherwise, keep the slashes as #000 black and lighten the path
> components a bit.

I suspect you would find it too faint again.

> Alternatively, we could have them (and other separators like ?, & and #) bold
> in both the textbox form and the non-focussed form. I seem to remember you made
> that possible at one point. But perhaps that had technical issues.

It had. Maybe somebody but me could do that.

> > You cannot trust yourbank.xxx.com, and users should look at
> > xxx.com first to get that.
> 
> On the other hand, there are advantages to TLD + 2. For example, consider
> "gerv.blogspot.com".

And what about gerv.blogs.mozilla.org? The line that you want to draw is actually independent from the TLD length; it varies from site to site. Plus, the intended security win is negated with TLD + N (N > 1). So the question imho is: TLD + 1 or no splitting at all?

> How about a darker blue, for example? I don't know if I'll find a better colour
> until I can try some :-)

Btw, until I implement this (I'm not really convinced yet), you can also use the DOM Inspector to add style="color:foo" to the domain node.

> It is allowed to encode spaces as a "+" in URLs, isn't it, as well as %20?
> Perhaps the textbox version could keep everything encoded, but have spaces as
> +.

It depends on the server to decode "+" into a space. E.g. see http://php.net/rawurldecode vs. http://php.net/urldecode.

> That way, there's less jumping between versions than if you had to replace
> space with %20.

There's no jumping currently, as both visible representations of the address are decoded. 20% will only be in your clipboard.

(In reply to comment #183)
> So what system color name will get you the current red, blue and green that the
> prefs offer? Or are they not system colours?

the latter

> Is there a list of system colour names and suggested uses somewhere?

http://www.w3.org/TR/CSS21/ui.html#system-colors

One of the ThreeD* values could be an option, but I'm not sure if they can be used safely as text colors, with -moz-field in the background.
Comment 185 Dão Gottwald [:dao] 2007-03-07 02:26:27 PST
filed bug 373011
Comment 186 Gervase Markham [:gerv] 2007-03-08 08:59:50 PST
> The line that you want to draw is
> actually independent from the TLD length; it varies from site to site. Plus,
> the intended security win is negated with TLD + N (N > 1).

It's not independent; saying so is the old computer programmers, "0, 1 or an infinite number" fallacy. There are far more gerv.blogspot.com-type sites than there are gerv.blogs.subsubdomain.subdomain.example.com sites. And the intended security win is not entirely negated for N > 1; it decreases as N increases. Like I said, we want to try out N = 2 and see if it's an overall improvement. And we can't do that unless you at least make it an option :-) "Let's try it" is not the same as "We're almost certainly going to do this."

> There's no jumping currently, as both visible representations of the address
> are decoded. 20% will only be in your clipboard.

The problem with that is, as someone commented in the newsgroup, it does mean that you can have URLs which look in the URL bar like you can see all of them but in fact you cannot. I don't think URLs should ever display with spaces in for this reason.

> It depends on the server to decode "+" into a space.

Well, all URL decoding depends on the server! I'm not sure what you mean here.

As for system colours, the list presented at the URL doesn't have enough different options. Which is fair enough; it's not supposed to be an exhaustive list. We use colours elsewhere in the interface which aren't system colours (e.g. the icons, or 'HTTPS yellow'). Yes, we'd need a way to make sure the text was always readable (perhaps by comparing to the background colour) but if we had that, then I don't see why we can't choose a colour.

Gerv
Comment 187 Caio Tiago Oliveira (asrail) 2007-03-08 10:52:49 PST
(In reply to comment #186)
> 
> > There's no jumping currently, as both visible representations of the address
> > are decoded. 20% will only be in your clipboard.
> 
> The problem with that is, as someone commented in the newsgroup, it does mean
> that you can have URLs which look in the URL bar like you can see all of them
> but in fact you cannot. I don't think URLs should ever display with spaces in
> for this reason.

Using the X11 clipboard also would fail.

> > It depends on the server to decode "+" into a space.
> 
> Well, all URL decoding depends on the server! I'm not sure what you mean
> here.

Some servers don't decode + as a space, so %20 is not strictly equals to +.
Wikipedia uses a _ as an alias to a space, but it decodes %20 but not +.

> As for system colours, the list presented at the URL doesn't have enough
> different options. Which is fair enough; it's not supposed to be an exhaustive
> list. We use colours elsewhere in the interface which aren't system colours
> (e.g. the icons, or 'HTTPS yellow'). Yes, we'd need a way to make sure the text
> was always readable (perhaps by comparing to the background colour) but if we
> had that, then I don't see why we can't choose a colour.
> 

Some people don't distinguish blue from black, some people don't distinguish blue from yellow.
So, for some people, a blue domain would fade into the background or not to be distinguishable from the rest of the text in the URL:
http://en.wikipedia.org/wiki/Color_blindness

Some people don't distinguish any color at all, only contrasts, so doesn't there is a perfect way for everyone and customizing is worth.
Comment 188 Dão Gottwald [:dao] 2007-03-08 11:36:22 PST
(In reply to comment #186)
> It's not independent; saying so is the old computer programmers, "0, 1 or an
> infinite number" fallacy. There are far more gerv.blogspot.com-type sites than
> there are gerv.blogs.subsubdomain.subdomain.example.com sites.

So there will be a billion happy first-level-subdomain gervs (no offence, but that includes phishers :-), and a million sad second-level-subdomain gervs. While I don't understand why someone should be sad because his whatever-level subdomain is grey (like all others), I do understand that the second-level subdomain doesn't want to be second class when a first-level subdomain is first class, for reasons that are beyond my horizon. Which leads to the mentioned conclusion: downgrade all subdomains or just leave it.

Mind that the whole idea behind splitting and highlighting was to reduce spoofing risk. Are there more yourbank.xxx.com than yourbank.xxx.yyy.com-type sites? At least, there /will/ be more once the first subdomain is highlighted.

> And the intended
> security win is not entirely negated for N > 1; it decreases as N increases.

It isn't harder or even less popular to create yourbank.xxx.com instead of yourbank.xxx.yyy.com. Thus I stick to it, the security win is lost if you highlight the first subdomain; it can even be negative, if you promote the highlighting as an anti-spoofing helper -- which was the original idea.

> Like I said, we want to try out N = 2 and see if it's an overall improvement.
> And we can't do that unless you at least make it an option :-) "Let's try it"
> is not the same as "We're almost certainly going to do this."

FWIW, it's "we're most certainly not going to do this." I really don't see the logics behind N = 2. I mean, not at all. Having your personal subdomain highlighted is nicer? Okay. Having www highlighted is nicer? Question of taste. Are these weighty arguments against N = 1? I strongly doubt that. If they were, we shouldn't split anywhere but say goodbye to whole idea (see above). I don't feel the need to try it, because the relevant facts are assessable.

> > There's no jumping currently, as both visible representations of the address
> > are decoded. 20% will only be in your clipboard.
> 
> The problem with that is, as someone commented in the newsgroup, it does mean
> that you can have URLs which look in the URL bar like you can see all of them
> but in fact you cannot. I don't think URLs should ever display with spaces in
> for this reason.

In the next release, I'm introducing a tooltip for URLs that exceed the text box.
We could also try to display · for spaces in the formatted view. I wonder if that dot has the width of a space for all fonts.

> > It depends on the server to decode "+" into a space.
> 
> Well, all URL decoding depends on the server! I'm not sure what you mean here.

I mean that %20 is the standard. If you type a space in the address bar, it will be submitted as %20. %20 is also covered by either of the PHP functions that I referred to.

> As for system colours, the list presented at the URL doesn't have enough
> different options. Which is fair enough; it's not supposed to be an exhaustive
> list. We use colours elsewhere in the interface which aren't system colours
> (e.g. the icons, or 'HTTPS yellow').

The HTTPS colors (yellow and black, both hard-coded) are completely independent of the system, so the problem doesn't exist there.

> Yes, we'd need a way to make sure the text
> was always readable (perhaps by comparing to the background colour) but if we
> had that, then I don't see why we can't choose a colour.

If we had that, I would agree. But that should be a core functionality so that we can use |color: -moz-foo|. I wouldn't want to do the analysis of the background in the binding, because that could break themes that use a background image. If we stick to CSS, theme authors can just replace -moz-foo by their preferred colors.
Comment 189 Dão Gottwald [:dao] 2007-03-09 07:16:53 PST
(In reply to comment #188)
> > > There's no jumping currently, as both visible representations of the address
> > > are decoded. 20% will only be in your clipboard.
> > 
> > The problem with that is, as someone commented in the newsgroup, it does mean
> > that you can have URLs which look in the URL bar like you can see all of them
> > but in fact you cannot. I don't think URLs should ever display with spaces in
> > for this reason.
> 
> In the next release, I'm introducing a tooltip for URLs that exceed the text
> box.
> We could also try to display · for spaces in the formatted view. I wonder if
> that dot has the width of a space for all fonts.

In addition to the tooltip, 0.9 displays an ellipsis at the end.
Comment 190 Dão Gottwald [:dao] 2007-03-15 14:04:16 PDT
Created attachment 258709 [details]
secure site UI

That's where I am UI-wise.

two issues with the implementation:
- as far as I can tell, there's no EV knowledge so far
- I have no clue how to extract the country code from the certificate
Comment 191 Dão Gottwald [:dao] 2007-03-15 16:11:01 PDT
Created attachment 258731 [details]
1.0a1

see previous comment
Comment 192 Dão Gottwald [:dao] 2007-03-15 16:22:39 PDT
Created attachment 258732 [details]
alternative secure site UI (organization on the left)
Comment 193 Gervase Markham [:gerv] 2007-03-16 09:52:23 PDT
> alternative secure site UI (organization on the right)

You mean the left, don't you?

I believe this (the second attachment) is the correct location for it - displacing the domain name, and thereby making a significant difference to the format of the location bar.

You are right that, at the moment, you can't possibly tell whether a cert is EV. That requires changes to NSS to expose this information. You may wish to implement a switch for turning this UI on for testing (for all certs), defaulting it to off. The information you are using is not sufficiently reliable outside of EV certs IMO, and displaying it in a way that leads people to trust it isn't a good thing.

As for getting the country code, can you do it the same way the certificate viewer (double-click the lock and click View) does it?

Gerv
Comment 194 Dão Gottwald [:dao] 2007-03-16 11:36:02 PDT
(In reply to comment #193)
> > alternative secure site UI (organization on the right)
> 
> You mean the left, don't you?

Well ... yes.

> I believe this (the second attachment) is the correct location for it -
> displacing the domain name, and thereby making a significant difference to the
> format of the location bar.

It's certainly more prominent on the left, but relocating the input field felt a bit odd to me. I guess it takes some time to get used to it.
Eventually, I'd be fine with either solution.

> You are right that, at the moment, you can't possibly tell whether a cert is
> EV. That requires changes to NSS to expose this information.

According to <http://en.wikipedia.org/wiki/Extended_Validation_Certificate#Extended_Validation_certificate_identification>, I could do it based on the OID. However, that's definitely something that should be left to NSS.

> You may wish to
> implement a switch for turning this UI on for testing (for all certs),
> defaulting it to off. The information you are using is not sufficiently
> reliable outside of EV certs IMO, and displaying it in a way that leads people
> to trust it isn't a good thing.

Yes. There's already a pref for moving the security information from the status bar to the location bar. I'll make it default to false until the EV and country code issues are cleared.

> As for getting the country code, can you do it the same way the certificate
> viewer (double-click the lock and click View) does it?

That's a magic tree-thingy; didn't make me any wiser.
Comment 195 Dão Gottwald [:dao] 2007-03-16 16:45:46 PDT
(In reply to comment #194)
> > As for getting the country code, can you do it the same way the certificate
> > viewer (double-click the lock and click View) does it?
> 
> That's a magic tree-thingy; didn't make me any wiser.

I was close. There was probably a QueryInterface missing or so.
This works for now:

> var certDumpTree = Components.classes["@mozilla.org/security/nsASN1Tree;1"]
>                              .createInstance(Components.interfaces.nsIASN1Tree);
> certDumpTree.loadASN1Structure(cert.ASN1Structure);
> var subject = certDumpTree.QueryInterface(Components.interfaces.nsIASN1Tree)
>                           .getDisplayData(9)
>                           .split(/\n| = /g);
> var iCountry = subject.indexOf("C");
> countryLabel.value = iCountry > -1 ?
>                      subject[iCountry + 1] :
>                      "";

Still quite ugly.
Comment 196 Dão Gottwald [:dao] 2007-03-16 17:47:50 PDT
Created attachment 258861 [details]
1.0a2
Comment 197 Modex 2007-03-17 10:01:02 PDT
Hi! I have feature request.
Often when I type address I still switch keyboard layout...
Can you add, than locationbar check that first symbol in eglish and if it not - switch layout automatically...
Comment 198 Dão Gottwald [:dao] 2007-03-17 10:54:46 PDT
(In reply to comment #197)
Please file a separate bug / enhancement request.
Comment 199 Dão Gottwald [:dao] 2007-04-03 01:49:33 PDT
I didn't get a response upon my Labs request. And actually, in order to deal with regressions, I prefer landing this ASAP (targeting Alpha 4, or Alpha 5 at the latest).
Therefore I'd like to drop linkification and the Extended Validation UI. The latter should be added later depending on bug 374336, which is my only real blocker at the moment.
Comment 200 Gervase Markham [:gerv] 2007-04-03 03:30:41 PDT
Dao: OK. Then I suggest the following course of action:

- Create a build of the extension which has, by default, exactly the options you are suggesting for checkin. Then we can do a formal ui review. My signoff is not good enough; we need to get beltzner involved.

- Once the final feature set is decided, you can turn the extension into a trunk patch. (This could retain all the hidden prefs but would have either none or very little of the pref UI.)

- That patch can then be code-reviewed by a Firefox front end hacker.

- Profit! Sorry, I mean: Checkin! :-)

Gerv
Comment 201 Dão Gottwald [:dao] 2007-04-03 11:37:45 PDT
Created attachment 260492 [details]
0.9.0.3 for UI review
Comment 202 Modex 2007-04-04 02:45:07 PDT
Why at _http://www.ftp.afips.ru/%cf%f0%ee%f7%e5%e5/ URL in address bar encoded?
Comment 203 Dão Gottwald [:dao] 2007-04-04 02:58:11 PDT
Because that's not utf-8.
Comment 204 Ka-Ping Yee 2007-04-11 12:01:35 PDT
(First a process comment and then a design comment.  Process comment:)

Yikes -- there are a lot of changes being proposed here all at once, and there
are many small decisions for each of them.  May I suggest narrowing the focus
and talking about one thing at a time?

For me the highest-priority feature is the domain highlighting, since it helps
the user with a common and important parsing task.  It's an easy win because
it can be added without replacing existing interaction or other features.
I'd like to know if you agree.

If so, I recommend focusing on that first and making a modest change to get
there (remember there are tens of millions of users who know and use the
current location bar).

The big design question is the URL appearance during normal browsing, and
there are plenty of design choices to be settled there yet (e.g. font, colour,
weight, style -- see http://wiki.mozilla.org/Firefox3/Location_Bar).  It would
be a good idea to get that figured out before talking about keybindings for
editing, fade transitions, certificate data, linkification, etc.

What is the best forum for discussing this?  Here or the Location_Bar wiki page?
Comment 205 Ka-Ping Yee 2007-04-11 12:20:24 PDT
(Design comment:)

My opinion of the appearance (from looking at the attached image at
https://bugzilla.mozilla.org/attachment.cgi?id=258709) is that the current
design is much too busy.

My current location bar has 4 visual elements:
  - favicon
  - URL
  - padlock
  - dropdown triangle

I count a whopping 11 elements in the proposed design image:
  - grey domain part
  - black domain part
  - URL path
  - ellipsis
  - RSS icon
  - vertical bar
  - padlock
  - organization name
  - country abbreviation
  - dropdown triangle
  - go triangle

That's just too much.  Let's keep it simple.

Despite the drawbacks of raw URLs, one huge advantage they have is a clear
feedback loop.  What you see in the URL field is exactly what you can type
into another URL field to get to the same place.  It's obvious what to
type because there's only one thing that looks like text in the field, and
it fills almost the whole field.  Please don't break that feedback loop.

I fear the possibility of users scratching their heads over how to enter
URLs in other location bars, or reproduce URLs in e-mail or on business cards.
How many spaces should I type between path segments?  Do I type the dots?
Are "Mozilla Foundation" and "US" part of the address?
Comment 206 Dão Gottwald [:dao] 2007-04-11 14:46:08 PDT
(In reply to comment #204)
> Yikes -- there are a lot of changes being proposed here all at once, and there
> are many small decisions for each of them.  May I suggest narrowing the focus
> and talking about one thing at a time?

You mean in separate bugs? I'm open to that, although, if beltzner gives a positive ui-review, a big patch would be easier for me.

Note that this isn't a rush with a lot of changes being proposed /all at once/, but the result of a rather long journey. Everything has been discussed here, in the newsgroups, on my own site. And there's Gerv's proposal, which I've tried to follow closely.

> For me the highest-priority feature is the domain highlighting, since it helps
> the user with a common and important parsing task.  It's an easy win because
> it can be added without replacing existing interaction or other features.
> I'd like to know if you agree.

I agree that it deserves the highest priority. However, implementing it requires a new binding with the switching between formatted and classic view, which doesn't make it an "easy win" compared to the other features.

> The big design question is the URL appearance during normal browsing, and
> there are plenty of design choices to be settled there yet (e.g. font, colour,
> weight, style -- see http://wiki.mozilla.org/Firefox3/Location_Bar).  It would
> be a good idea to get that figured out before talking about keybindings for
> editing, fade transitions, certificate data, linkification, etc.

Again, all of this has been discussed. So far, I don't see real alternatives when it comes to "font, colour, weight, style".

> What is the best forum for discussing this?  Here or the Location_Bar wiki
> page?

mozilla.dev.apps.firefox. This bug is getting too long and there's no discussion going on in the wiki.

(In reply to comment #205)
> My current location bar has 4 visual elements:
>   - favicon
>   - URL
>   - padlock
>   - dropdown triangle
> 
> I count a whopping 11 elements in the proposed design image:
>   - grey domain part
>   - black domain part
>   - URL path
>   - ellipsis
>   - RSS icon
>   - vertical bar
>   - padlock
>   - organization name
>   - country abbreviation
>   - dropdown triangle
>   - go triangle

1. The "RSS icon" and the "go triangle" are elements of the current location
   bar.
2. "grey domain part", "black domain part", "URL path", "ellipsis" and
   "vertical bar" are no distinct elements.
3. The security UI would probably be removed from the status bar.

> I fear the possibility of users scratching their heads over how to enter
> URLs in other location bars, or reproduce URLs in e-mail or on business cards.
> How many spaces should I type between path segments?  Do I type the dots?
> Are "Mozilla Foundation" and "US" part of the address?

As soon as you try to type into the bar, you see the classic address. At the same time, by making the host more prominent, the formatted view is more consistent with how most users understand and use addresses. I think the handling of the two modes is sensible enough.
Comment 207 Ka-Ping Yee 2007-04-11 15:27:15 PDT
(In reply to comment #206)
> I agree that it deserves the highest priority. However, implementing it
> requires a new binding with the switching between formatted and classic view,
> which doesn't make it an "easy win" compared to the other features.

By "easy win" I mean obvious benefit and low cost to the user (not ease of
implementation).  The decision to go with the new design is only complicated
if one assumes there has to be a complex mode switch "between formatted and
classic view".

Won't this be much simpler if we just grey out the rest (non-TLD+1) of the
URL when the location bar lacks focus, and leave everything else the same?

> Again, all of this has been discussed. So far, I don't see real alternatives
> when it comes to "font, colour, weight, style".

I'm not sure what you count as "real", but these are still listed as open
issues on the wiki page, and the thread on mozilla.dev.apps.firefox has a wide
array of suggestions.

Thanks for the pointer to the newsgroup.  I'll catch up over there.
Comment 208 Ka-Ping Yee 2007-04-13 06:10:51 PDT
> Won't this be much simpler if we just grey out the rest (non-TLD+1) of the
> URL when the location bar lacks focus, and leave everything else the same?

This is now mocked up at http://zesty.ca/mozilla/locbar.html for those who
are interested in seeing it.
Comment 209 Merlyel 2007-05-15 07:47:58 PDT
Got one feature request: when entering URL without any additional parameters (e.g. http://mozilla-russia.org) breadcumb is shown too (http://merlyel.reslex.net/images/breadcumb.png). I think it should not be there in such cases :)
Comment 210 Marco Bonardo [::mak] (Away 6-20 Aug) 2007-05-15 08:11:40 PDT
i'm using 0.9.1.0 because of grey subdomains support on 2.x, and i have show favicon enabled.
Suppose i'm loading a page, then i decide to stop load, i go to the toolbar and click stop. 
then i move to the location bar to write a new address, but locationbar now shows me the link because i've entered the location from the favicon side. I have to move away (down) and go back, and this happens frequently to me while using the toolbar icons.

I think that the links should be showed only with modifiers key (shift - ctrl) and not on normal entering into the locationbar from any side. 

thank you
Comment 211 Dão Gottwald [:dao] 2007-05-15 08:32:44 PDT
Breadcrumbs and linkification aren't goals of this bug anymore.
Comment 212 Dão Gottwald [:dao] 2007-05-21 06:45:56 PDT
Created attachment 265510 [details]
0.9.0.4: No hidden protocols, all gray but eTLD+2, fully encoded Unicode URLs

Per <http://weblogs.mozillazine.org/gerv/archives/2007/05/location_bar_proposal_1.html>. 

I consider these changes a regression, compared to 0.9.0.3. Sadly, I don't even find the result significantly better than the plain old urlbar. (I haven't removed the overflow ellipsis and tooltip yet, which leaves a notable improvement at least.)

I'm disappointed by the way this has been discussed (privately, that is) and communicated. They only /propose/ something, yeah, but with Gerv, Jonathan and Mike B. behind it, I don't see room for fundamental objections.

I don't see my concerns against eTLD+2 (comment 188) addressed. And I don't follow "these two things are where we want to start, and then we can look at further changes". We've already looked at further changes, and it seems that we throw away the chance to really have them tested.
Comment 213 Jesse Ruderman 2007-05-21 07:20:44 PDT
I agree with Dao: highlighting eTLD+2 doesn't make any sense.  It would make phishing easy (yourbank.evil.com) and determining whether you're on a real facebook / livejournal / blogspot subdomain hard (because too much would be highlighted).  It would also fail to give users the right mental model about hostname ownership.
Comment 214 Gervase Markham [:gerv] 2007-05-21 07:29:36 PDT
> I'm disappointed by the way this has been discussed (privately, that is) and
> communicated. They only /propose/ something, yeah, but with Gerv, Jonathan and
> Mike B. behind it, I don't see room for fundamental objections.

What can I say? Someone has to make a decision, and they have the UI design expertise. You asked for ui review on your patch - this is the result.

I really do mean it when I say the 2 is a first attempt. But I don't agree with Jesse's points. Your bank's ads tell you to visit "bankofamerica.com". "bankofamerica.something.com" does not look like bankofamerica.com. bankofamerica.com.something.com _does_, but that wouldn't all be highlighted using ETLD+2.

As for the other half, I don't understand your point. How is "too much" highlighted in the blogspot case?
www.GERV.BLOGSPOT.COM/archive/...

There are several shopping meta-sites which are shopname.host.com; highlighting only host.com gives the wrong mental model about site ownership in that case. It's not all one way.

We are going to start with 2 and see what happens. 3 is very unlikely. We may well end up with 1, if 2 turns out to have too many downsides.

Dao: I'll certainly have a look at the tooltip and ellipsis. Off the top of my head, it depends where the tooltip appears; if it covers part of the URL bar, that would be bad. And it shouldn't appear unless there's an ellipsis.

Gerv
Comment 215 Jesse Ruderman 2007-05-21 07:52:54 PDT
> Your bank's ads tell you to visit "bankofamerica.com".
> "bankofamerica.something.com" does not look like bankofamerica.com.
> bankofamerica.com.something.com _does_, but that wouldn't all be highlighted
> using ETLD+2.

But in bankofamerica.com-evil.com, the entire "bankofamerica.com" string *would* be highlighted.

ETLD+2 also makes www-bankofamerica.com look too similar to www.bankofamerica.com.

If we highlight ETLD+2, we'll have to continue teaching users how to parse hostnames in their head: that dots separate parts of hostnames (and hyphens don't), that hostnames are read right-to-left, etc.

Highlighting ETLD+1 would help users avoid phishing.  Highlighting ETLD+2 would help phishers.

> As for the other half, I don't understand your point. How is "too much"
> highlighted in the blogspot case?
> www.GERV.BLOGSPOT.COM/archive/...

When I decide whether to type my password into the comment form on someone.blogspot.com, I need to determine whether I'm really on a blogspot.com blog.  Having "gerv" highlighted makes that harder, especially given things like "gerv-blogspot.com".  Same with facebook, which makes me log in every time I visit.

> There are several shopping meta-sites which are shopname.host.com; highlighting
> only host.com gives the wrong mental model about site ownership in that case.
> It's not all one way.

Those sites are rare, and they're set up like that *because* they want to ensure users that it's safe to enter their credit card number *despite* the small-shop nature of the site.  (Centralized credit card processing ftw.)  So highlighting ETLD+1 is absolutely the right thing to do for those sites.

I'm not sure I made my point about mental models clear.  My point is: after seeing many examples like "mit.facebook.com" with only "facebook.com" highlighted and "www.ebay.com" with only "ebay.com" highlighted, many users will come to understand hostname ownership without us having to teach them explicitly.
Comment 216 Robert Sayre 2007-05-21 08:18:49 PDT
(In reply to comment #215)
> 
> If we highlight ETLD+2, we'll have to continue teaching users how to parse
> hostnames in their head: 

That's a pretty positive way to put it. Users will continue to fail to interpret the URL bar. Lots of them don't even notice the lock or the yellow background:

http://people.deas.harvard.edu/~rachna/papers/why_phishing_works.pdf

> that dots separate parts of hostnames (and hyphens
> don't), that hostnames are read right-to-left, etc.

Don't forget to add the bit about the hierarchy then changing directions in the path.

         <----------------------|---------->
  http://baz.bar.foo.example.com/foo/bar/baz

What could be easier? Oh, let's add the little detail that lots of web sites make the host hierarchy appear to move left to right, because they start with "www".

         <--------------|---------->
  http://www.example.com/foo/bar/baz

I have anecdotal evidence that many users will parse this left-to-right as follows:

  [http:// ] -> [      www.    ] -> [example.com] -> [/foo/bar/baz]
  [  JUNK  ] -> [World Wide Web] -> [    site   ] -> [   folders  ]

and then you get to explain that, actually, "www" doesn't really mean anything.

Comment 217 Gervase Markham [:gerv] 2007-05-21 08:53:54 PDT
OK, calm down everyone. How many times do I have to say it? It's what we want to try out to start with. That is not code for "we've made a decision" or "your arguments all suck and we're going to ignore them". It's code for "it's what we want to try out to start with".

That's what the trunk is for. Experimentation. We want to do a UI experiment. Entire back-end modules get turned on and off on a weekly basis and no-one bats an eyelid. But when we suggest trying out a relatively tiny change to the UI, suddenly there's uproar.

Gerv
Comment 218 Brendan Eich [:brendan] 2007-05-21 09:53:41 PDT
http://blog.nbc.com/CreedThoughts/2007/05/creed_thoughts.php

Ryan: Last year Creed asked me how to set up a blog. Wanting to protect the world from being exposed to Creed’s brain, I opened up a Word document on his computer and put an address at the top. I’ve read some of it. Even for the Internet, it’s ... pretty shocking.

/be
Comment 219 Brendan Eich [:brendan] 2007-05-21 10:01:05 PDT
Gerv: why not run the experiment with an addon? Or if you really want to cook in the kitchen, then take the heat and respond to critical feedback before launching, not after.

/be
Comment 220 Brendan Eich [:brendan] 2007-05-21 11:12:16 PDT
In case it was unclear, comment 218 is a humorous reference and quote to the U.S. version of "The Office", which is actually relevant to this bug.

/be
Comment 221 :Ehsan Akhgari (away Aug 1-5) 2007-05-23 00:06:25 PDT
One point that annoys me is whether the decision to remove the favicon completely in accordance with the "Don't break stuff people use" requirement on <http://wiki.mozilla.org/Firefox3/Location_Bar>.  People can drag the favicon to the Home button on the toolbar to make the currently viewed page their home page.  I personally know a lot of users which are amazed by the simplicity of changing their home page (no need to move around the Options dialog.)  However, removing this element renders this feature unusable.  Should we consider providing an alternative for this feature?
Comment 222 :Ehsan Akhgari (away Aug 1-5) 2007-05-23 00:15:10 PDT
(In reply to comment #221)
> One point that annoys me is whether the decision to remove the favicon
> completely in accordance with the "Don't break stuff people use" requirement on
> <http://wiki.mozilla.org/Firefox3/Location_Bar>.  People can drag the favicon
> to the Home button on the toolbar to make the currently viewed page their home
> page.  I personally know a lot of users which are amazed by the simplicity of
> changing their home page (no need to move around the Options dialog.)  However,
> removing this element renders this feature unusable.  Should we consider
> providing an alternative for this feature?
> 

I forgot to mention that I understand that dragging the selected URL still works, but first of all the browser.urlbar.clickSelectsAll pref might be set to false (requiring the user to select the URL manually, which may be error prone especially if the URL is long and doesn't fit in the location bar, which may cause the user to select part of the URL unintentionally), and in addition, the user may not know that she can drag the URL itself to the Home button as well.
Comment 223 Brendan Eich [:brendan] 2007-05-23 00:17:16 PDT
Re: comment 221 -- why are so many changes being mixed together under a bug whose summary reads "Revise the Location Bar"? Ok, dumb question. The summary is much to broad. Can we return this bug to sanity and make it be about highlighting ETLD+1 and file other bugs for other damage?

/be
Comment 224 Dão Gottwald [:dao] 2007-05-23 01:42:56 PDT
(In reply to comment #221)
> One point that annoys me is whether the decision to remove the favicon
> completely in accordance with the "Don't break stuff people use" requirement on
> <http://wiki.mozilla.org/Firefox3/Location_Bar>.  People can drag the favicon
> to the Home button on the toolbar to make the currently viewed page their home
> page.

Tabs have a favicon, too. Cf. bug 372773.

(In reply to comment #223)
It was a long way till 0.9.0.3. I understand that people joining the discussion now find this bug confusing, but it was a natural, evolutionary process. Jumping in and saying things that have been discussed before doesn't really help. It's even worse if there's no reasoning at all, as in Gerv's blog post (which was *not* a UI review of my work, btw) -- where's "hide protocols"? It was my impression that we had reached agreement on that long before. Now Gerv's comment about experimenting on the trunk seems to be the opposite of what's actually happening.

Having that said, I'm okay with splitting the bug. Specifically, I've never planned to really post a patch that removes the favicon here, since it will be a little more complex than setting hidden="true" on the favicon container (though, if we get one UI review here, that will make it easier to proceed). I do, however, believe that the main infrastructure that's behind 0.9.0.3 and 0.9.0.4 should land here, so that hiding certain protocols in a follow-up bug will be as easy as changing a pref.
Comment 225 Mike Connor [:mconnor] 2007-05-23 08:45:13 PDT
If the favicon is ok in the tabstrip, why is is a bad thing in the URL bar?  I think I'd want to avoid killing the favicon in the first step, and just do the domain highlighting here.

Can we get a patch that leaves the favicon intact and keeps the rest of the current impl?  I'd like to get this into alpha 5 if possible, though its been a while since I've seen the current code.
Comment 226 Dão Gottwald [:dao] 2007-05-23 09:46:06 PDT
(In reply to comment #225)
> Can we get a patch that leaves the favicon intact and keeps the rest of the
> current impl?

Yes, that was my plan.

> I'd like to get this into alpha 5 if possible, though its been a
> while since I've seen the current code.

I'll post a patch shortly.
Comment 227 Ka-Ping Yee 2007-05-23 13:50:12 PDT
(In reply to comment #225)
> If the favicon is ok in the tabstrip, why is is a bad thing in the URL bar?

Because the location bar is trusted chrome.  Security information goes in the location bar, but not in the tabstrip.  Removing the favicon from the location bar is necessary to uphold the integrity of that security information.
Comment 228 Dão Gottwald [:dao] 2007-05-23 16:49:11 PDT
Created attachment 265863 [details] [diff] [review]
patch v1

Like 0.9.0.4, but highlighting eTLD+1 and leaving the favicon. The latter should be addressed in a separate bug.

If this is desired to make alpha 5, someone will have to review it quickly. I don't know if mconnor has that time.

Note that I didn't have the time to test the patch. (But I did test an updated extension that looks 99 per cent like the patch.)
Comment 229 Dão Gottwald [:dao] 2007-05-24 00:24:53 PDT
Created attachment 265907 [details] [diff] [review]
patch v2

little cleanup, nothing dramatic.

Again, I don't know if mconnor has the time to review this. I suppose you (browser peers) will sort it out yourselves.
Comment 230 Gervase Markham [:gerv] 2007-05-24 07:29:09 PDT
> Or if you really want to cook
> in the kitchen, then take the heat and respond to critical feedback before
> launching, not after.

Mike, Jonathan and I looked at the issue, taking into account all the points of view and feedback, and decided to do this. No-one has raised any new points here that we didn't take into account when we discussed it. We want to try +2, see how it goes, and revert to +1 if it turns out the downsides are big.

Re Brendan's other comment: I wasn't actually anticipating that this bug would be used for *any* of the work, as it's so full. But this plan is good too.

(In reply to comment #224)
> It's even worse if there's no reasoning at all, as in Gerv's blog post
> (which was *not* a UI review of my work, btw) 

That's not what I said. You asked for a ui-review by setting a flag. Mike, Jonathan and I did one and discussed the options, including all the things that have been tried. We decided that some of the changes were more obvious wins than others, and so we were going to start with those. So the blogpost was the results of the review, not the review itself.

Gerv
Comment 231 Brendan Eich [:brendan] 2007-05-24 07:45:39 PDT
(In reply to comment #230)
> > Or if you really want to cook
> > in the kitchen, then take the heat and respond to critical feedback before
> > launching, not after.
> 
> Mike, Jonathan and I looked at the issue, taking into account all the points of
> view and feedback, and decided to do this.

Sorry, that's not good enough. At this point, we need a rationale that says why Jesse's arguments are not valid or sound. Either he's making invalid inferences, or one or more of his premises are false.

> No-one has raised any new points
> here that we didn't take into account when we discussed it.

That's really great. So you must have better arguments than Jesse's.

> We want to try +2,
> see how it goes, and revert to +1 if it turns out the downsides are big.

This isn't entirely an empirical problem. It's possible to reason about it as Jesse did, based in part on the nature of domain names.

/be
Comment 232 Gervase Markham [:gerv] 2007-05-24 10:17:31 PDT
OK, here we go again. A point-by-point:

(In reply to comment #215)
> > Your bank's ads tell you to visit "bankofamerica.com".
> > "bankofamerica.something.com" does not look like bankofamerica.com.
> > bankofamerica.com.something.com _does_, but that wouldn't all be highlighted
> > using ETLD+2.
> 
> But in bankofamerica.com-evil.com, the entire "bankofamerica.com" string
> *would* be highlighted.

As it would in bankofamerica-com-evil.com. If you are going to argue that no-one understands separators, then the pendulum doesn't just stop there.

> If we highlight ETLD+2, we'll have to continue teaching users how to parse
> hostnames in their head: that dots separate parts of hostnames (and hyphens
> don't), that hostnames are read right-to-left, etc.

They need to know that anyway - see above.

> When I decide whether to type my password into the comment form on
> someone.blogspot.com, I need to determine whether I'm really on a blogspot.com
> blog.  Having "gerv" highlighted makes that harder, especially given things
> like "gerv-blogspot.com".  Same with facebook, which makes me log in every 
> time
> I visit.

But on the other hand, if the gerv is greyed out, that makes it much easier for one sub-site to pretend to be another. 

> > There are several shopping meta-sites which are shopname.host.com; highlighting
> > only host.com gives the wrong mental model about site ownership in that case.
> > It's not all one way.
> 
> Those sites are rare, and they're set up like that *because* they want to
> ensure users that it's safe to enter their credit card number *despite* the
> small-shop nature of the site.  (Centralized credit card processing ftw.) 

Right. And if we grey out the distinctive part of the name of their site, that's going to be a disincentive to act in this way.

Also, if a consumer has a problem with wibble.yahooshops.com, and yahooshops.com is highlighted, who are they going to complain to? Yahoo.

My point is _not_ that +2 is clearly better than +1. It is that there are arguments on both sides, and both sides can quote examples which work better with their position. So my suggestion, and Mike, Jonathan and my plan, was to try +2, and see if there were obvious breakages, then try +1 and see if there are obvious breakages. Maybe 2 weeks each, or something.

So actually the people who have to make the really strong argument are those who claim that +1 is so much of a slamdunk that it's not worth even trying +2.

Gerv
Comment 233 Robert Sayre 2007-05-24 10:29:22 PDT
(In reply to comment #232)
> OK, here we go again. A point-by-point:
> 
> (In reply to comment #215)
> > > Your bank's ads tell you to visit "bankofamerica.com".
> > > "bankofamerica.something.com" does not look like bankofamerica.com.
> > > bankofamerica.com.something.com _does_, but that wouldn't all be highlighted
> > > using ETLD+2.
> > 
> > But in bankofamerica.com-evil.com, the entire "bankofamerica.com" string
> > *would* be highlighted.
> 
> As it would in bankofamerica-com-evil.com. If you are going to argue that
> no-one understands separators, then the pendulum doesn't just stop there.

Agree.

> 
> > If we highlight ETLD+2, we'll have to continue teaching users how to parse
> > hostnames in their head: that dots separate parts of hostnames (and hyphens
> > don't), that hostnames are read right-to-left, etc.
> 
> They need to know that anyway - see above.
> 
> > When I decide whether to type my password into the comment form on
> > someone.blogspot.com, I need to determine whether I'm really on a blogspot.com
> > blog.  Having "gerv" highlighted makes that harder, especially given things
> > like "gerv-blogspot.com".  Same with facebook, which makes me log in every 
> > time
> > I visit.
> 
> But on the other hand, if the gerv is greyed out, that makes it much easier for
> one sub-site to pretend to be another. 
> 

This doesn't seem like a useful threat to address. These sites are centrally administered, so it's much easier to address spoofing and similar attacks. If it hurts our ability to help users identify spoof *domains* in general, then it is extremely damaging and we shouldn't do it.

> > > There are several shopping meta-sites which are shopname.host.com; highlighting
> > > only host.com gives the wrong mental model about site ownership in that case.
> > > It's not all one way.
> > 
> > Those sites are rare, and they're set up like that *because* they want to
> > ensure users that it's safe to enter their credit card number *despite* the
> > small-shop nature of the site.  (Centralized credit card processing ftw.) 
> 
> Right. And if we grey out the distinctive part of the name of their site,
> that's going to be a disincentive to act in this way.
> 
> Also, if a consumer has a problem with wibble.yahooshops.com, and
> yahooshops.com is highlighted, who are they going to complain to? Yahoo.
> 

Yes. I don't see a problem with that. Yahoo needs to be careful about the types of businesses they host.

> My point is _not_ that +2 is clearly better than +1. It is that there are
> arguments on both sides, and both sides can quote examples which work better
> with their position.

I feel that the threat posed by spoofed domains is much greater. The examples used for +2 are much less compelling.

Comment 234 Justin Dolske [:Dolske] 2007-05-24 10:52:06 PDT
(In reply to comment #232)
> Right. And if we grey out the distinctive part of the name of their site,
> that's going to be a disincentive to act in this way.

Perhaps this issue can be addressed by making sure that this part of the URL is simply styled in a way that is different from TLD+X, but not in a way that makes it look hidden / greyed out.
Comment 235 Jesse Ruderman 2007-05-24 12:28:52 PDT
(In reply to comment #232)
> > But in bankofamerica.com-evil.com, the entire "bankofamerica.com" string
> > *would* be highlighted.
> 
> As it would in bankofamerica-com-evil.com. If you are going to argue that
> no-one understands separators, then the pendulum doesn't just stop there.

If users are looking for the string "bankofamerica.com" to be highlighted, they'll correctly notice that something is wrong with "bankofamerica-com-evil.com".  Not noticing the difference between a hyphen and a dot is not the same thing as not knowing that dots are special when parsing hostnames.

More to the point is "evil-bankofamerica.com", which would all be highlighted.  I guess users will have to expect that "bankofamerica.com" (and only "bankofamerica.com") should be highlighted.  That's not ideal, but it's a lot better than expecting users to figure out how to parse entire hostnames in their head without any hints.
Comment 236 Dão Gottwald [:dao] 2007-05-24 12:36:54 PDT
(In reply to comment #234)
> (In reply to comment #232)
> > Right. And if we grey out the distinctive part of the name of their site,
> > that's going to be a disincentive to act in this way.
> 
> Perhaps this issue can be addressed by making sure that this part of the URL is
> simply styled in a way that is different from TLD+X, but not in a way that
> makes it look hidden / greyed out.

You get that distinction automatically by hiding the protocol, e.g.:

  [    shopname.HOST.COM    /foo/?bar=x   ]

instead of

  [ http://shopname.HOST.COM/foo/?bar=x   ]
Comment 237 Ed Lee :Mardak 2007-05-24 12:57:34 PDT
(In reply to comment #236)
> (In reply to comment #234)
> > simply styled in a way that is different from TLD+X, but not in a way that
> > makes it look hidden / greyed out.
> You get that distinction automatically by hiding the protocol

The problem is that for average users, *if* they look at the location bar and actually realize the domain is important because it's unfaded, the remainder seems equally unimportant; they won't realize the text left of the important thing is actually somewhat important.

E.g., using Dolske's suggestion; domain = black, subdomain = dark gray, path/etc = light gray

Another way is as you have with LocationBar2 - put whitespace after the domain to push away the path/etc.
Comment 238 Dão Gottwald [:dao] 2007-05-24 13:18:50 PDT
(In reply to comment #237)
> E.g., using Dolske's suggestion; domain = black, subdomain = dark gray,
> path/etc = light gray

I'm not convinced that this would look clear. But we don't have native gray tones besides 'graytext' anyway. We'd have to use opacity (which is somewhat broken for text) or use non-native colors all the way.

> Another way is as you have with LocationBar2 - put whitespace after the domain
> to push away the path/etc.

That's what I meant. The whitespace originates from the hidden protocol.
Comment 239 Gervase Markham [:gerv] 2007-05-25 07:56:42 PDT
Guys, we're off into the weeds again. In the first iteration, we aren't using multiple colours, and we aren't hiding the protocol (just greying it out). 

What has ui-review+ is highlighting the TLD + 2 (for the moment), and hiding the favicon. 

Would it make you all feel better about trialling +2 if I said that I suspect you may be right about +1? I still want to try +2 though, and ask our testers to report pros and cons from sites that they browse - then do the same with +1.

Gerv
Comment 240 Dão Gottwald [:dao] 2007-05-25 11:58:12 PDT
(In reply to comment #239)
> Guys, we're off into the weeds again. In the first iteration, we aren't using
> multiple colours, and we aren't hiding the protocol (just greying it out). 

Apparently it's all connected. Highlighting eTLD+1 looks, of course, significantly worse if the subdomain merges with the protocol into a gray mass.

> What has ui-review+ is highlighting the TLD + 2 (for the moment), and hiding
> the favicon. 

You've been the only one briefly arguing for eTLD+2, which makes me wonder if you've been lobbying beltzner a bit to review particularly your vision. Combined with the closed nature of that review, I don't think I can accept the result.
I'm not going to attach a patch for eTLD+2 unless beltzner shows up for a statement that's at least distantly related to a kosher review.

> Would it make you all feel better about trialling +2 if I said that I suspect
> you may be right about +1?

Well, that would make the whole discussion way more ridicules. If you agree that eTLD+2 gives the wrong idea about trusted ownership and is therefore not an option, there's no point in testing it.

> I still want to try +2 though, and ask our testers
> to report pros and cons from sites that they browse - then do the same with +1.

What do you expect of that? There will be complaints that wannabe TLDs like "de.vu" are highlight without the subdomain, I grant you that. But it's rather unlikely that our testers complain about being phished or having to parse URLs resp. hostnames.
Comment 241 Robert Sayre 2007-05-25 18:37:13 PDT
(In reply to comment #240)
> 
> You've been the only one briefly arguing for eTLD+2, which makes me wonder if
> you've been lobbying beltzner a bit to review particularly your vision.
> Combined with the closed nature of that review, I don't think I can accept the
> result.

I don't think there's a problem with Gerv and Beltzner discussing this problem in person, off the record.

I do expect a coherent response to security concerns raised by Jesse, myself, and others. I understand that security often comes at the expense of usability, so I welcome clear descriptions of the trade-offs we're making. So far, there is no justification for exposing the "+2" solution to nightly testers. I would never release it as an alpha or beta.
Comment 242 Ian Pottinger 2007-05-25 22:22:39 PDT
Highlighting eTLD+1 seem like a logical thing for a browser to do irrespective of any phishing issues.  I see it as a simplified version of the "alternative secure site UI" (attachment #258732 [details]) discussed earlier.  As Dão and others have convincingly argued, it allows more users to more likely parse something meaningful from the Location Bar.  If sometimes it helps to identify phishing attempts then that is a pleasant happenstance.

eTLD+(>1) highlighting, however, is some other creature - in this case a proposed anti-phishing UI.  Unfortunately in that regard, it introduces all the disadvantages levied at both eTLD+1 and eTLD+2 highlighting, most notably the problem of misinterpretation by uneducated users.

On the one hand, eTLD+1 highlighting looks like a useful and meaningful revision to the Location Bar. Isn't that what this bug really is about?  On the other hand, eTLD+1 and eTLD+2 highlighting are arguably problematic anti-phishing UI proposals and can easily be considered out of scope for this bug.  I'd like to see anti-phishing concerns abandoned for now to be address elsewhere and a renewed concentration on revisions that are less controversial.
Comment 243 Dão Gottwald [:dao] 2007-05-25 23:52:07 PDT
(In reply to comment #241)
> (In reply to comment #240)
> > 
> > You've been the only one briefly arguing for eTLD+2, which makes me wonder if
> > you've been lobbying beltzner a bit to review particularly your vision.
> > Combined with the closed nature of that review, I don't think I can accept the
> > result.
> 
> I don't think there's a problem with Gerv and Beltzner discussing this problem
> in person, off the record.

Me neither, as long as it's discussed impartially and all participants get a chance to comprehend the outcome.
Comment 244 Dão Gottwald [:dao] 2007-05-26 01:23:27 PDT
Created attachment 266170 [details] [diff] [review]
patch v3

More cleanup, nothing critical again (see interdiff). Actually the code should be pretty stable. Given the wide test coverage of the extension, I guess there's still a tiny chance for this to make a5, assuming beltzner is okay with highlighting eTLD+1.
Comment 245 Dão Gottwald [:dao] 2007-05-26 14:41:57 PDT
Created attachment 266219 [details] [diff] [review]
patch v4

um, missed the jar.mn update ...
Comment 246 Mike Beltzner [:beltzner, not reading bugmail] 2007-05-28 12:54:29 PDT
(In reply to comment #230)
> Mike, Jonathan and I looked at the issue, taking into account all the points 
> of view and feedback, and decided to do this. No-one has raised any new points
> here that we didn't take into account when we discussed it. We want to try +2,
> see how it goes, and revert to +1 if it turns out the downsides are big.

That's not entirely accurate, Gerv, and it's a little upsetting for me to be misrepresented like this. When you and I talked about it, the discussion was rushed and mostly about the UI elements we wanted to enable on the trunk. I specifically remember asking what "ETLD + 2" meant, and you rushed an explanation of how it was required for broad web-compatibility issues, and made it sound very much like fait-accompli in terms of agreement with other people who'd looked at the issue.

It was under that context that I said "yeah, then, let's go".
 
(In reply to comment #231)
> Sorry, that's not good enough. At this point, we need a rationale that says 
> why Jesse's arguments are not valid or sound. Either he's making invalid
> inferences, or one or more of his premises are false.

That's exactly right.

> This isn't entirely an empirical problem. It's possible to reason about it as
> Jesse did, based in part on the nature of domain names.

As is that.

This bug is huge now, and it's hard to understand what it is that I'm meant to deliberate on for a ui-review. My goals here are to get the UI differences (support for non-latin characters in URIs, highlighting domain names and removing favicons from the location bar) onto trunk to try and see what that feels like. In that spirit, it feels to me like ETLD+1 is probably the best thing to do here; if it turns out to be disorienting for the reasons Gerv suggests, we'll discover that over time with usage.

Someone put up that patch and you'll find that it gets my ui-r.
Comment 247 Dão Gottwald [:dao] 2007-05-28 14:30:26 PDT
Created attachment 266423 [details] [diff] [review]
patch v5

some notes:

* support for non-latin characters in URIs

  This is quite hackerish, because I'm bypassing the default cmd_copy / cmd_cut
  actions in order to make sure that the copied value is useful (i.e. encoded)
  for other applications. Maybe the reviewer has a hint for me how to do that
  better, or we just pass it to a follow-up bug. In order to move on, I prefer
  the latter.

* removing favicons from the location bar

  Simply done with a <xul:hbox hidden="true"> container. I don't want to remove
  the relevant browser.xul and browser.js code until we know how the final UI
  will look like.

* also hiding protocols (http://, https://, file://, ftp://) as agreed on IRC:

  <beltzner> yeah, I'm actually really for it
  [...]
  <johnath>  yeah - hooray for hiding protocols
  <beltzner> I don't see a *strong* security argument for it, and again, it's
             the sort of thing where we'll get to guage discomfort pretty well
Comment 248 Gervase Markham [:gerv] 2007-05-28 14:36:50 PDT
Mike: I didn't mean it to sound like a fait accompli; sorry it came across that way. I presented the counter-argument - which was basically, at the time, that it made phishing easier - and my reasons for thinking that was not the case. We went through some examples. I still believe both are worth trying; but if I'm the only person who thinks that, so be it :-)

I know this bug is huge; IMO we should have moved to another one for the actual trunk patches. But never mind.

How is this protocol hiding going to work? Does this mean that text moves around when you focus the URL bar? Or is the protocol still hidden even in that case? I don't really like the behaviour of the current Locationbar2, although it's better than the days when the entire URL moved.

Gerv
Comment 249 Dão Gottwald [:dao] 2007-05-28 15:04:59 PDT
(In reply to comment #248)
> I know this bug is huge; IMO we should have moved to another one for the actual
> trunk patches. But never mind.

I do hope we can shut this bug down soon. There might be open issues that can be handled elsewhere.

> How is this protocol hiding going to work? Does this mean that text moves
> around when you focus the URL bar?

The host moves around, indeed. I've synced the extension with the recent patch: http://design-noir.de/mozilla/locationbar2/0.9.0.4-r.xpi
If that turns out to be annoying to users, we can still try to come up with other solutions or, as a last resort, flip the pref.

> Or is the protocol still hidden even in that case?

IMO that would only work for http:// (or ftp:// if the host starts with "ftp."). Other protocols would get lost when editing the URL.
Comment 250 Ka-Ping Yee 2007-05-28 15:30:25 PDT
> > How is this protocol hiding going to work? Does this mean that text moves
> > around when you focus the URL bar?
> 
> The host moves around, indeed.

Ugh -- I'm not happy about this.  The whole point was to keep the text from
moving around.  I thought one of the principles we had agreed on was to not
have the URL jump around, so we could avoid introducing a new UI
surprise/annoyance every time you try to edit a URL.

I'd rather keep this simple, as Gerv proposed: (a) help the user find the
relevant domain name and (b) prevent favicons from spoofing security
indicators.  There's no need to do more beyond that; that's just change
for the sake of change, in my opinion.
Comment 251 Unknown W. Brackets 2007-05-28 15:36:45 PDT
(In reply to comment #247)
> * also hiding protocols (http://, https://, file://, ftp://) as agreed on IRC:
> 
>   <beltzner> yeah, I'm actually really for it
>   [...]
>   <johnath>  yeah - hooray for hiding protocols
>   <beltzner> I don't see a *strong* security argument for it, and again, it's
>              the sort of thing where we'll get to guage discomfort pretty well

This bug is already too long, and I'm nobody, but I just wanted to say:

Just because users don't care doesn't mean it doesn't matter.  Often times I'm dealing with clients for websites my company has built for them, and having them read their address bar to me is *absolutely crucial* when dealing with ftp or https.  When they report bugs, sometimes the difference between http and https is the bug - but they don't realize this.

I know of no quicker way to get the information from someone who doesn't understand the difference.  If they did, I would think hiding the protocol would cause much less detriment.

-[Unknown]
Comment 252 Brendan Eich [:brendan] 2007-05-28 19:49:42 PDT
I'm going to try to avoid sounding like I'm throwing weight around, and just say that comment 250 and comment 251 both make important points:

* Don't jiggle graphical layout for no or bad reasons.
* Don't hide concrete information that can't be abstractd from the user's model.

It's also important to avoid taking a hit from too much change for no clear win. Stripping scheme, especially with the text-jumps-on-focus bug, will cause a loud counter-reaction. It's completely predictable. Don't go there.

And to repeat something many have said: don't change several variables at once, don't mix independent issues in one bug. You will be sorry.

/be
Comment 253 Jesse Ruderman 2007-05-28 21:20:57 PDT
I think the "highlight the eTLD+1" change and the "remove the site's icon from the address bar" change (bug 382220) should happen on different days so we can see how users react to each change.
Comment 254 Mike Beltzner [:beltzner, not reading bugmail] 2007-05-29 00:03:29 PDT
(In reply to comment #252)
> I'm going to try to avoid sounding like I'm throwing weight around, and just
> say that comment 250 and comment 251 both make important points:
> 
> * Don't jiggle graphical layout for no or bad reasons.

I agree with this, and didn't realize that my support for stripping the protocol prefix implied that I would be supporting the text jiggle. I want the prefix stripped, period. If it's important to the user to enter it, they can do so, and it will then vanish, poof. If it's important for the user to understand their prefix, or important for tech support to get at it, they can Page Info to victory or whatever.

> * Don't hide concrete information that can't be abstractd from the user's
> model.

For the vast majority of users, the difference between http://, https://, ftp://, file://, and the like is absolutely meaningless. It's implementation model holdover and we should see what it's like without it.

I don't think we should abstract it, I think we should remove it, as it doesn't *exist* in the user's model.

> And to repeat something many have said: don't change several variables at 
> once, don't mix independent issues in one bug. You will be sorry.

This does make sense. I'd love to see these split out into several patches. Perhaps this can be done during the code review phase to give Dao some much needed support?
Comment 255 Dão Gottwald [:dao] 2007-05-29 00:26:02 PDT
Comment on attachment 266423 [details] [diff] [review]
patch v5

Okay, let's flip this:

>+pref("browser.urlbar.hideProtocols", "http https file ftp");

to:

>+pref("browser.urlbar.hideProtocols", "");

(In reply to comment #251)
> Often times I'm
> dealing with clients for websites my company has built for them, and having
> them read their address bar to me is *absolutely crucial* when dealing with ftp
> or https.

You'll be able to change the pref.

> When they report bugs, sometimes the difference between http and
> https is the bug - but they don't realize this.

The address will always contain the protocol when copying & pasting it.
Comment 256 Unknown W. Brackets 2007-05-29 00:50:07 PDT
(In reply to comment #255)
> > Often times I'm
> > dealing with clients for websites my company has built for them, and having
> > them read their address bar to me is *absolutely crucial* when dealing with ftp
> > or https.
> 
> You'll be able to change the pref.

That's livable.  Most of my clients (read: third parties who hire my company on contract/bid basis, sometimes through a middle man called an ad agency) would be scared of about:config like most people are afraid of wolves, but it is something I could walk them through.

> > When they report bugs, sometimes the difference between http and
> > https is the bug - but they don't realize this.
> 
> The address will always contain the protocol when copying & pasting it.

As much as people know what Ctrl-C does, it amazes me that many people don't actually realize when it's prudent to use it.  I get things retyped (with typos, even!) all the time.  Or screenshots - those are very common, but most of the time I could at least find the lock.

Still, I see the arguments as "this makes it more difficult" vs. "the user doesn't care".  Similarly, most users don't care about the Bookmarks toolbar (almost everyone I see has it empty, wasting space, not knowing how to remove it) - does that mean it should be off except through a pref too?

Query strings and fragments also commonly make no sense to the user.  Go to Gmail and tell me you can read that.  I can't decode base64 (if that is what it is) in my head... sounds like another thing that should be taken away.  Developers can have it back with a pref too, nay?

-[Unknown]
Comment 257 Ka-Ping Yee 2007-05-29 00:57:51 PDT
(In reply to comment #254)
> I want the prefix stripped, period. If it's important to the user
> to enter it, they can do so, and it will then vanish, poof. If it's
> important for the user to understand their prefix, or important for
> tech support to get at it, they can Page Info to victory or whatever.

I'm afraid I disagree with you here.  It is no more reasonable to
hide the protocol than it is to hide the ".com" at the end of a domain
name.  The protocol is a real part of the URL; changing it gets you to
a different place.

I also strongly agree with what Brendan said in #252 about not changing
lots of variables at once.  Even if you eventually decide to hide the
scheme, it's definitely not the first priority -- there is a clear
anti-spoofing benefit to be gained from emphasizing the eTLD+1, so let's
do that first.  Hiding the favicon would be the next priority (we get
an anti-spoofing benefit, but lose some currently used functionality).
Comment 258 Ka-Ping Yee 2007-05-29 01:07:01 PDT
(In reply to comment #255)
> > When they report bugs, sometimes the difference between http and
> > https is the bug - but they don't realize this.
> 
> The address will always contain the protocol when copying & pasting it.

I don't understand how this can work.  If the protocol is hidden,
how can you tell when the user intends to copy a selection containing
the protocol and when the user intends to copy a selection without
the protocol?  Does the decision to add the protocol to the clipboard
depend on whether the first character is selected, or whether the
entire URL is selected, or something else?  What if I drag-select just
the domain name, for example?  Is there a difference between
drag-selecting the URL from beginning to end, and pressing Ctrl-A?

Any criterion I can think of for deciding whether or not to prepend
the protocol to the clipboard seems unnecessarily arbitrary and magical.

If we leave the protocol there, the way it is now, the copy/paste
behaviour is obvious: what you see is what you get.
Comment 259 Dão Gottwald [:dao] 2007-05-29 01:13:55 PDT
(In reply to comment #256)
> Still, I see the arguments as "this makes it more difficult" vs. "the user
> doesn't care".  Similarly, most users don't care about the Bookmarks toolbar
> (almost everyone I see has it empty, wasting space, not knowing how to remove
> it) - does that mean it should be off except through a pref too?

That's hardly a simile.

> Query strings and fragments also commonly make no sense to the user.  Go to
> Gmail and tell me you can read that.  I can't decode base64 (if that is what it
> is) in my head... sounds like another thing that should be taken away. 
> Developers can have it back with a pref too, nay?

That's not a simile either. I'm a developer, yet I don't need to see protocols. Also, it's impossible for us to tell whether a query string contains important and human readable information.

Btw, we could also think about presetting the pref to "http https file". Those URLs are visually differentiable even without the explicit scheme.

(In reply to comment #257)
> I also strongly agree with what Brendan said in #252 about not changing
> lots of variables at once.

Fine, although there's no need to agree strongly. It has already been said that the protocol won't be hidden in the first run.

(In reply to comment #258)
> > The address will always contain the protocol when copying & pasting it.
> 
> I don't understand how this can work.  If the protocol is hidden,
> how can you tell when the user intends to copy a selection containing
> the protocol and when the user intends to copy a selection without
> the protocol?

It has been said how this works, it was part of the several proposals, and you can try it yourself with the extension that I referred to.
Comment 260 Dão Gottwald [:dao] 2007-06-03 07:23:14 PDT
Comment on attachment 266423 [details] [diff] [review]
patch v5

beltzner: When reviewing this, please go to about:config and set browser.urlbar.hideProtocols to an empty string. (Just in case that wasn't clear.)
Comment 261 Simon Bünzli 2007-06-05 13:04:09 PDT
Dão: I've resurrected urlbarBindings.xml in bug 295498. The new bindings should now probably be added to that file as well.

Furthermore I'd rather keep the page proxy icon around for the first tests (i.e. just don't display a favicon in its stead) - if only for esthetical reasons: it makes the urlbar look like more than any common text box (especially when it's empty); it more closely mirrors the search box (icon to the left, arrow to the right); and it's been around since the days of IE 4 and Mozilla 0.6 (i.e. about a decade) and is nowadays part of every major browser.
Comment 262 Elmar Ludwig 2007-06-05 13:50:25 PDT
(In reply to comment #261)
> Furthermore I'd rather keep the page proxy icon around for the first tests
> (i.e. just don't display a favicon in its stead) - if only for esthetical
> reasons:

Removing it breaks also some current functionality (drag & drop, bug 291768, bug 302660).
Comment 263 Dão Gottwald [:dao] 2007-06-05 14:00:28 PDT
Created attachment 267324 [details] [diff] [review]
patch v6

(In reply to comment #261)
> Dão: I've resurrected urlbarBindings.xml in bug 295498. The new bindings
> should now probably be added to that file as well.

Roger that.

> Furthermore I'd rather keep the page proxy icon around for the first tests
> (i.e. just don't display a favicon in its stead)

I have a patch for that in bug 382220.
But not displaying any icon seems like a valuable experiment. It can be reverted easily by removing <xul:hbox hidden="true">, as I'm not killing any code yet.

> - if only for esthetical
> reasons: it makes the urlbar look like more than any common text box
> (especially when it's empty); it more closely mirrors the search box (icon to
> the left, arrow to the right); and it's been around since the days of IE 4 and
> Mozilla 0.6 (i.e. about a decade)

I don't think that's a good enough reason for carrying dead GUI elements around. If we find another use for that, fine, but the page proxy icon alone seems pointless.
Comment 264 Mike Beltzner [:beltzner, not reading bugmail] 2007-06-06 04:40:10 PDT
Comment on attachment 267324 [details] [diff] [review]
patch v6

This is an odd sort of ui-r+ since I'm approving this for experimentation on the trunk.

mconnor, please review the code and determine if you want to land both of these UI changes in a single patch. I think we should just get it done so that more people can play around with it and see how it feels.
Comment 265 :Gavin Sharp [email: gavin@gavinsharp.com] 2007-06-25 22:15:21 PDT
Comment on attachment 267324 [details] [diff] [review]
patch v6

>Index: browser/base/content/urlbarBindings.xml

>+        <!--XXX interim solution for hiding the favicon (bug 382220): -->
>+        <xul:hbox hidden="true">
>+          <children includes="image|deck|stack">
>+            <xul:image class="autocomplete-icon" allowevents="true"/>
>+          </children>
>+        </xul:hbox>

Discussed this with mconnor/beltzner, let's leave this out for now and do the favicon removal separately (in bug 382220?)

>+      <field name="_animateBlend"/>
> ... lots more fields ...

I recall a bug about field evaluation taking a lot of time, and perf wins from just setting JS properties in the constructor rather than declaring them in <field>s ahead of time. If this causes a perf regression (Ts) we'll need to keep that in mind.

>+      <field name="_dndObserver" readonly="true"><![CDATA[({

Isn't this just duplicating urlbarObserver from browser.js? I don't see why you need the ondragover/ondragenter handlers at all, and if the browser.js code works then you should be able to just remove this.

>+            urlSecurityCheck(url, gBrowser.currentURI.spec,
>+                             Components.interfaces.nsIScriptSecurityManager.DISALLOW_INHERIT_PRINCIPAL);

If you do end up keeping this, you need to fix it. urlSecurityCheck no longer takes a URI spec for the second param, it now takes a principal. You probably want gBrowser.contentPrincipal in this case. I think you should also be consistent and use either getBrowser() or gBrowser, but not both.

>+      <field name="_plain">true</field>
>+      <property name="plain" onget="return this._plain">
>+        <setter><![CDATA[
>+          this._plain = val;

Sounds like you want this to be a boolean, in which case you should assign !!val to _plain.

>+          while (this._blendingTimers.length)
>+            clearTimeout(this._blendingTimers.pop());
>+          if (val) {
>+            this._inputBox.style.removeProperty("opacity");
>+            this._presentationBox.hidden = true;
>+          } else {
>+            this._inputBox.style.setProperty("opacity", "0", "important");
>+          }

Shouldn't this styling be done via a class instead of modifying the style directly here?

>+          this._presentationBox.style.removeProperty("opacity");
>+          this._hideURLTooltip();
>+          return val;
>+        ]]></setter>
>+      </property>

>+      <method name="_syncValue">
>+        <parameter name="explicitValue"/>

Please add an "a" prefix for argument names.

>+          if (value == "")
>+            this._uri = null;
>+          else try {
>+            var uri = this._ioService.newURI(value, null, null);
>+            this._uri = (typeof uri.host != "undefined") ? uri : null;
>+          } catch(e) {
>+            this._uri = null;
>+          }

This syntax looks a bit strange, please bracket the else clause and indent the try normally. I'm also not sure that the typeof check is useful... .host will either throw or return a value, I don't see how it could ever be undefined. You might also add a comment that you're relying on the host getter throwing here to avoid having to catch exceptions later on when getting e.g. uri.port.

>+          var host = this._uri.host;
>+          if (host) {

Is it possible for host to be blank? When?

>+            var asciiHost = this._uri.asciiHost;

Looks like this is only used inside the next condition, please declare it there.

>+            //XXX workaround for bug 364129
>+            if (!/^[.0-9]+$/.test(host)) {
>+              var domainSegments = host.split(".");
>+              var cSubdomain = domainSegments.length -
>+                               asciiHost.slice(asciiHost.length -
>+                                               this._tldService.getEffectiveTLDLength(asciiHost))
>+                                        .split(".").length - 1;
>+              if (cSubdomain > 0) {
>+                host = domainSegments;
>+                var subdomain = host.splice(0, cSubdomain);
>+                this._subDomainNode.value = subdomain.join(".") + ".";
>+                host = host.join(".");
>+              }
>+            }

Could you comment this code a bit? It's hard to follow what it's doing.

>+          var pathSegments = this._decodeURI(this._uri.path.substring(1));

>+          // fragment identifier
>+          // query string

Can't you QI the URI to nsIURL and get these (filePath, ref, query) that way instead of doing manual string munging?

>+      <method name="_copy">
>+      <method name="_cut">

These functions share a large amount of code, can't your refactor them so that there's no unneeded duplication?

>+      <method name="_initURLTooltip">

>+          this._tooltipTimer = setTimeout(function(self) {
...
>+          }, 400, this);
>+        ]]></body>
>+      </method>

Why 400? I dislike arbitrary timers like this, but if it absolutely must be greater than 0, please file a bug. I suspect this could be removed once the popup rewrite lands (bug 279703).

>+      <handler event="keypress" phase="capturing" key="c" modifiers="accel"
>+               action="this._copy(event)"/>
>+      <handler event="keypress" phase="capturing" key="x" modifiers="accel"
>+               action="this._cut(event)"/>
>+#if defined(XP_WIN) || defined(XP_UNIX)
>+      <handler event="keypress" phase="capturing" keycode="VK_INSERT" modifiers="control"
>+               action="this._copy(event)"/>
>+      <handler event="keypress" keycode="VK_DELETE" modifiers="shift"
>+               action="this._cut(event)"/>
>+#endif
>+#ifdef XP_UNIX
>+      <handler event="keypress" keycode="VK_DELETE" modifiers="control"
>+               action="this._copy(event)"/>
>+#endif

XP_UNIX is defined on Mac and Linux. Given that, are these conditions correct? Do you want |#ifndef (XP_MACOSX)|? If all you want to do is override the default clipboard controllers you should just implement nsIController for the clipboard commands, and call something like urlBar.controllers.insertControllerAt(0, yourController); (you might need to add it to the anonymous html:input rather than the url bar element itself). Once you do this you should be able to remove the doCommand overriding in the constructor, too.

>+      <handler event="mousemove"><![CDATA[
>+        if (!this._focused && this._contentIsCropped)
>+          this._initURLTooltip(function() {
>+            return this.plain ? this.value : null;
>+          }, this, "start");
>+      ]]></handler>

>+      <handler event="mouseover"><![CDATA[

>+        if (!this.plain) {
>+          var pBO = this._presentationBox.boxObject;
>+          if (event.screenX < pBO.screenX || event.screenX > pBO.screenX + pBO.width)
>+            return;
>+        }

Can you add a comment describing the purpose of this code?

>+        this._mouseover = true;
>+        setTimeout(function(self) {
>+          if (self._mouseover) {
>+            self.plain = true;
>+            if (!self._focused && self._contentIsCropped)
>+              self._initURLTooltip(function() {
>+                return this.plain ? this.value : null;
>+              }, self, "start");
>+          }
>+        }, 60, this);

60 seems arbitrary, does 0 not work here?

>+      <handler event="mouseout"><![CDATA[
>+        for (var node = event.relatedTarget; node; node = node.parentNode)
>+          if (node == this)
>+            return;

Can you add a comment describing the purpose of this code?

>+  <binding id="urlbar-url-singlesegment" display="xul:hbox" extends="chrome://browser/content/urlbar.xml#urlbar-url-segment">
>+    <content>
>+      <xul:label class="textbox-presentation-segment-label" xbl:inherits="value"/>
>+      <xul:label class="textbox-presentation-slash" value="/"/>
>+    </content>
>+  </binding>

>+  <binding id="urlbar-url-filesegment" extends="chrome://browser/content/urlbar.xml#urlbar-url-segment">
>+    <content>
>+      <children/>
>+    </content>
>+  </binding>

Why do these bindings extend urlbar-url-segment if all they do is redefine it's content? urlbar-url-segment has no implementation, so I don't see the point.

>Index: browser/themes/pinstripe/browser/browser.css
>Index: browser/themes/winstripe/browser/browser.css

These comments apply to both files: 

> #urlbar {
>+  -moz-binding: url(chrome://browser/content/urlbar.xml#urlbar);

Since this rule is functional rather than presentational, I think it should be in browser/base/content/browser.css rather than in each theme-specific file.

>+.textbox-presentation-segment {
>+  -moz-binding: url(chrome://browser/content/urlbar.xml#urlbar-url-segment) !important;
>+}
>+.textbox-presentation-path {
>+  -moz-binding: url(chrome://browser/content/urlbar.xml#urlbar-url-singlesegment) !important;
>+}
>+.textbox-presentation-pathFile {
>+  -moz-binding: url(chrome://browser/content/urlbar.xml#urlbar-url-filesegment) !important;
>+}

Same comment about these being in the content browser.css.

>+#urlbar[level="high"] .textbox-presentation-segment > :not(.textbox-presentation-domain) ,
>+#urlbar[level="low"] .textbox-presentation-segment > :not(.textbox-presentation-domain) {
>+  color: rgb(150, 150, 130);
>+}

Is this hard coded color going to cause problems with high-contract or other customized OS themes?

Otherwise this looks OK. Has it been tested on all three platforms? With bidi enabled? High-contrast themes? Non-default font sizes? I can help test some of those scenarios if you need me to. I'd like to land this before the alpha 6 freeze (around Wed 9 AM Berlin time), so if you could get an updated patch put together and tested against trunk before then that'd be great.
Comment 266 Dão Gottwald [:dao] 2007-06-26 05:09:59 PDT
(In reply to comment #265)
> >+          while (this._blendingTimers.length)
> >+            clearTimeout(this._blendingTimers.pop());
> >+          if (val) {
> >+            this._inputBox.style.removeProperty("opacity");
> >+            this._presentationBox.hidden = true;
> >+          } else {
> >+            this._inputBox.style.setProperty("opacity", "0", "important");
> >+          }
> 
> Shouldn't this styling be done via a class instead of modifying the style
> directly here?

_prettyView modifies opacity too, and there I can't use classes. Mixing both seems more complex and error-prone to me.

> >+          var host = this._uri.host;
> >+          if (host) {
> 
> Is it possible for host to be blank? When?

Yes, file URIs have an empty host.

> >+      <method name="_initURLTooltip">
> 
> >+          this._tooltipTimer = setTimeout(function(self) {
> ...
> >+          }, 400, this);
> >+        ]]></body>
> >+      </method>
> 
> Why 400? I dislike arbitrary timers like this, but if it absolutely must be
> greater than 0, please file a bug. I suspect this could be removed once the
> popup rewrite lands (bug 279703).

The timer isn't needed technically. But do we want the popup to show up immediately?

> >+        this._mouseover = true;
> >+        setTimeout(function(self) {
> >+          if (self._mouseover) {
> >+            self.plain = true;
> >+            if (!self._focused && self._contentIsCropped)
> >+              self._initURLTooltip(function() {
> >+                return this.plain ? this.value : null;
> >+              }, self, "start");
> >+          }
> >+        }, 60, this);
> 
> 60 seems arbitrary, does 0 not work here?

Again, no technical reason. It's just to reduce flicker when passing the URL bar quickly.

> >+#urlbar[level="high"] .textbox-presentation-segment > :not(.textbox-presentation-domain) ,
> >+#urlbar[level="low"] .textbox-presentation-segment > :not(.textbox-presentation-domain) {
> >+  color: rgb(150, 150, 130);
> >+}
> 
> Is this hard coded color going to cause problems with high-contract or other
> customized OS themes?

The background is hard coded in that case as well.

> Otherwise this looks OK. Has it been tested on all three platforms? With bidi
> enabled? High-contrast themes? Non-default font sizes? I can help test some of
> those scenarios if you need me to.

Linux and Windows are tested; I can test high-contrast and font-sizes, bidi probably not. I can't test on Mac OS.
Comment 267 Dão Gottwald [:dao] 2007-06-26 06:30:14 PDT
Created attachment 269854 [details] [diff] [review]
patch v7

Still need to do the testing, but attaching it anyway since there's only little time left.
Comment 268 Dão Gottwald [:dao] 2007-06-26 06:42:32 PDT
Comment on attachment 269854 [details] [diff] [review]
patch v7

>+    <implementation implements="nsIObserver, nsIController">
>+      <constructor><![CDATA[

>+        this._inputBox.controllers.insertControllerAt(0, this);

doesn't work
Comment 269 :Gavin Sharp [email: gavin@gavinsharp.com] 2007-06-26 06:58:31 PDT
(In reply to comment #268)
> (From update of attachment 269854 [details] [diff] [review])
> >+    <implementation implements="nsIObserver, nsIController">
> >+      <constructor><![CDATA[
> 
> >+        this._inputBox.controllers.insertControllerAt(0, this);
> 
> doesn't work

You're inserting it into this._inputBox.controllers, did you try this.inputField.controllers?
Comment 270 Dão Gottwald [:dao] 2007-06-26 07:01:56 PDT
Yes, it's the wrong element. New patch coming in a minute.
Comment 271 Dão Gottwald [:dao] 2007-06-26 07:05:49 PDT
Created attachment 269856 [details] [diff] [review]
patch v7.1
Comment 272 Dão Gottwald [:dao] 2007-06-26 07:13:00 PDT
Created attachment 269857 [details] [diff] [review]
patch v7.2

disable commands if the selection is empty
Comment 273 Dão Gottwald [:dao] 2007-06-26 07:19:47 PDT
Created attachment 269858 [details] [diff] [review]
patch v7.3

getting closer ;)
my browser.js update was missing.
Comment 274 Dão Gottwald [:dao] 2007-06-26 07:36:12 PDT
My high-contrast theme and big font tests were successful. There's one theme where graytext doesn't differ from the normal color, but that shouldn't be a showstopper.
Comment 275 Dão Gottwald [:dao] 2007-06-26 07:49:09 PDT
Created attachment 269860 [details] [diff] [review]
patch v7.4

hopefully-fixed encoding, firefox.js updated to latest trunk
Comment 276 :Gavin Sharp [email: gavin@gavinsharp.com] 2007-06-26 12:28:20 PDT
Comment on attachment 269860 [details] [diff] [review]
patch v7.4

>Index: browser/base/content/browser.css

> /* ::::: location bar ::::: */
>+#urlbar {
>+  -moz-binding: url(chrome://browser/content/urlbar.xml#urlbar);
>+}

Fix this typo: urlbarBindings.xml.

>Index: browser/base/content/urlbarBindings.xml

>+          isCommandEnabled: function(aCommand) {
>+            return this.urlbar.selectionStart < this.urlbar.selectionEnd;
>+          },

I think you need to check that aCommand is one of the commands that your controller is handling (cmd_copy etc). Ideally callers would call supportsCommand before checking isCommandEnabled, but the API really isn't documented so I guess you're better off safe than sorry.

>+          onEvent: function(aEventName) {}
>+        };
>+        this.inputField.controllers.insertControllerAt(0, copyCutController);

Please also remove the controller in the destructor, since this will potentially cause cycles.

>+      <method name="_initURLTooltip">

Is this really needed? Can't you just dynamically adjust the tooltiptext attribute in _syncValue, instead of managing the tooltip yourself? We can do this in a followup bug.

r=me with those addressed. I've tested this on the Mac and Windows, and it looks fine. Let's get this landed!
Comment 277 Dão Gottwald [:dao] 2007-06-26 14:40:33 PDT
(In reply to comment #276)
> >+      <method name="_initURLTooltip">
> 
> Is this really needed? Can't you just dynamically adjust the tooltiptext
> attribute in _syncValue, instead of managing the tooltip yourself? We can do
> this in a followup bug.

Is there a way to crop tooltiptext at the start? crop=end would be worthless, which is why I've introduced a custom tooltip.
Comment 278 Dão Gottwald [:dao] 2007-06-26 14:42:06 PDT
Created attachment 269914 [details] [diff] [review]
patch for checkin
Comment 279 Shawn Wilsher :sdwilsh 2007-06-26 17:27:05 PDT
Checking in browser/base/content/browser.css;
new revision: 1.26; previous revision: 1.25
Checking in browser/base/content/browser.js;
new revision: 1.804; previous revision: 1.803
Checking in browser/base/content/browser.xul;
new revision: 1.343; previous revision: 1.342
Checking in browser/base/content/urlbarBindings.xml;
new revision: 1.5; previous revision: 1.4
Checking in browser/themes/pinstripe/browser/browser.css;
new revision: 1.51; previous revision: 1.50
Checking in browser/themes/winstripe/browser/browser.css;
new revision: 1.61; previous revision: 1.60
Comment 280 Dão Gottwald [:dao] 2007-06-26 18:26:48 PDT
Thanks Gerv, Gavin, Jesse, Ping, Beltzner and others who have been involved.
Everybody please file new bugs for regressions and open issues.
Comment 281 Shawn Wilsher :sdwilsh 2007-06-26 20:23:12 PDT
*sighs*

<sayrer> sdwilsh, it looks like the location bar is leaking

backing out...

Checking in browser/themes/winstripe/browser/browser.css;
new revision: 1.62; previous revision: 1.61
Checking in browser/themes/pinstripe/browser/browser.css;
new revision: 1.52; previous revision: 1.51
Checking in browser/base/content/urlbarBindings.xml;
new revision: 1.6; previous revision: 1.5
Checking in browser/base/content/browser.xul;
new revision: 1.344; previous revision: 1.343
Checking in browser/base/content/browser.js;
new revision: 1.805; previous revision: 1.804
Checking in browser/base/content/browser.css;
new revision: 1.27; previous revision: 1.26
Comment 282 David Baron :dbaron: ⌚️UTC+2 (mostly busy through August 4; review requests must explain patch) 2007-06-26 20:40:54 PDT
The leaks look related to a large hash table in necko.  Bug 385248 would let us debug a good bit better based on the tinderbox output alone -- probably the first thing to do is regenerate that output (i.e., do a --enable-trace-malloc build on Linux, run with --trace-malloc=/dev/null --shutdown-leaks=logfile1.txt, apply the patch, do the same with logfile2.txt, and then run diffbloatdump.pl on the resulting output to see which hash table it is.  Unless it's obvious to you based on:

  881406 malloc
    834300 PL_DHashAllocTable
      826200 PL_DHashTableInit
        826200 /builds/tinderbox/Fx-Trunk-Debug/Linux_2.6.9-42.ELsmp_Depend/mozilla/obj/dist/bin/components/libnecko.so+7822F
          826200 /builds/tinderbox/Fx-Trunk-Debug/Linux_2.6.9-42.ELsmp_Depend/mozilla/obj/dist/bin/components/libnecko.so+78274
            826200 /builds/tinderbox/Fx-Trunk-Debug/Linux_2.6.9-42.ELsmp_Depend/mozilla/obj/dist/bin/components/libnecko.so+76B0D
              826200 /builds/tinderbox/Fx-Trunk-Debug/Linux_2.6.9-42.ELsmp_Depend/mozilla/obj/dist/bin/components/libnecko.so+76CAE
                826200 /builds/tinderbox/Fx-Trunk-Debug/Linux_2.6.9-42.ELsmp_Depend/mozilla/obj/dist/bin/components/libnecko.so+76F4D
                  826200 /builds/tinderbox/Fx-Trunk-Debug/Linux_2.6.9-42.ELsmp_Depend/mozilla/obj/dist/bin/components/libnecko.so+7708D
                    826200 /builds/tinderbox/Fx-Trunk-Debug/Linux_2.6.9-42.ELsmp_Depend/mozilla/obj/dist/bin/components/libnecko.so+774EC
                      826200 /builds/tinderbox/Fx-Trunk-Debug/Linux_2.6.9-42.ELsmp_Depend/mozilla/obj/dist/bin/components/libnecko.so+18895
                        826200 /builds/tinderbox/Fx-Trunk-Debug/Linux_2.6.9-42.ELsmp_Depend/mozilla/obj/dist/bin/libxpcom_core.so+39C9A
                          826200 /builds/tinderbox/Fx-Trunk-Debug/Linux_2.6.9-42.ELsmp_Depend/mozilla/obj/dist/bin/libxpcom_core.so+9A2C9
                            826200 /builds/tinderbox/Fx-Trunk-Debug/Linux_2.6.9-42.ELsmp_Depend/mozilla/obj/dist/bin/libxpcom_core.so+9C225
                              826200 /builds/tinderbox/Fx-Trunk-Debug/Linux_2.6.9-42.ELsmp_Depend/mozilla/obj/dist/bin/components/libxpconnect.so+3D51A
                                826200 NS_InvokeByIndex_P
    103152 operator new(unsigned int)
      103000 /builds/tinderbox/Fx-Trunk-Debug/Linux_2.6.9-42.ELsmp_Depend/mozilla/obj/dist/bin/components/libnecko.so+76ACE
        103000 /builds/tinderbox/Fx-Trunk-Debug/Linux_2.6.9-42.ELsmp_Depend/mozilla/obj/dist/bin/components/libnecko.so+76CAE
          103000 /builds/tinderbox/Fx-Trunk-Debug/Linux_2.6.9-42.ELsmp_Depend/mozilla/obj/dist/bin/components/libnecko.so+76F4D
            103000 /builds/tinderbox/Fx-Trunk-Debug/Linux_2.6.9-42.ELsmp_Depend/mozilla/obj/dist/bin/components/libnecko.so+7708D
              103000 /builds/tinderbox/Fx-Trunk-Debug/Linux_2.6.9-42.ELsmp_Depend/mozilla/obj/dist/bin/components/libnecko.so+774EC
                103000 /builds/tinderbox/Fx-Trunk-Debug/Linux_2.6.9-42.ELsmp_Depend/mozilla/obj/dist/bin/components/libnecko.so+18895
                  103000 /builds/tinderbox/Fx-Trunk-Debug/Linux_2.6.9-42.ELsmp_Depend/mozilla/obj/dist/bin/libxpcom_core.so+39C9A
                    103000 /builds/tinderbox/Fx-Trunk-Debug/Linux_2.6.9-42.ELsmp_Depend/mozilla/obj/dist/bin/libxpcom_core.so+9A2C9
                      103000 /builds/tinderbox/Fx-Trunk-Debug/Linux_2.6.9-42.ELsmp_Depend/mozilla/obj/dist/bin/libxpcom_core.so+9C225
                        103000 /builds/tinderbox/Fx-Trunk-Debug/Linux_2.6.9-42.ELsmp_Depend/mozilla/obj/dist/bin/components/libxpconnect.so+3D51A
                          103000 NS_InvokeByIndex_P
                            103000 /builds/tinderbox/Fx-Trunk-Debug/Linux_2.6.9-42.ELsmp_Depend/mozilla/obj/dist/bin/components/libxpconnect.so+5B74A
                              103000 /builds/tinderbox/Fx-Trunk-Debug/Linux_2.6.9-42.ELsmp_Depend/mozilla/obj/dist/bin/components/libxpconnect.so+6A042
                                103000 js_Invoke
Comment 283 :Gavin Sharp [email: gavin@gavinsharp.com] 2007-06-26 20:51:15 PDT
Mano pointed out a few things earlier today that I missed when first reviewing: don't use fields if they're not needed (e.g. _animateBlend doesn't need a field, just set the property like you're currently doing), and don't have fields that call getService() in their initializer, since that ends up happening too early, which can cause performance issues when parsing the XBL. In the case of _tldService and _ioService, you can either just inline the getService() calls, since they're used pretty infrequently, or use an XBL property with a getter and a field to cache the value (and then release it in the destructor). Mano found some other issues that he said he was going to file a bug on, but I suspect losing the reference to the TLD service will fix the leak problem.
Comment 284 Dão Gottwald [:dao] 2007-06-27 00:41:15 PDT
Created attachment 269990 [details] [diff] [review]
follow-up
Comment 285 Dão Gottwald [:dao] 2007-06-27 00:51:03 PDT
getService() in the constructor is okay, isn't it? Or should I use properties with getters + shadow fields?
Comment 286 Dão Gottwald [:dao] 2007-06-27 05:44:14 PDT
Created attachment 270007 [details] [diff] [review]
patch v8

I took the opportunity to do some refactoring:
- added a formatted-url binding which can be used independently from #urlbar
- browser.urlbar.* pref handling moved from browser.js to the #urlbar binding
Comment 287 Dão Gottwald [:dao] 2007-06-27 06:19:26 PDT
Comment on attachment 270007 [details] [diff] [review]
patch v8

let's leave that to a follow-up bug
Comment 288 :Gavin Sharp [email: gavin@gavinsharp.com] 2007-06-27 07:15:52 PDT
Comment on attachment 269990 [details] [diff] [review]
follow-up

I'm going to try landing this again once the tree is green.
Comment 289 :Gavin Sharp [email: gavin@gavinsharp.com] 2007-06-27 23:53:27 PDT
This was landed again, but had to be disabled due to Lk and Ts/Txul regressions. I think the use of the TLD service is responsible for both; I'll look into it further tomorrow.
Comment 290 Dão Gottwald [:dao] 2007-06-28 01:20:02 PDT
Thanks for investigating, Gavin. Also thanks for leaving it in the tree -- do you think dependent bugs like bug 190615 can already be addressed, or could it be backed out again?
Comment 291 David Baron :dbaron: ⌚️UTC+2 (mostly busy through August 4; review requests must explain patch) 2007-06-28 01:26:57 PDT
I filed the leak as bug 386155 and the ridiculous memory usage of the effective TLD service as bug 386154.  It's probably easiest to fix both at once.
Comment 292 David Baron :dbaron: ⌚️UTC+2 (mostly busy through August 4; review requests must explain patch) 2007-06-28 01:56:12 PDT
(In reply to comment #282)
> probably the
> first thing to do is regenerate that output (i.e., do a --enable-trace-malloc
> build on Linux, run with --trace-malloc=/dev/null
> --shutdown-leaks=logfile1.txt, apply the patch, do the same with logfile2.txt,
> and then run diffbloatdump.pl on the resulting output to see which hash table
> it is.

Note that I missed one step:  you want to use the --use-address argument to tools/trace-malloc/diffbloatdump.pl so that you can run tools/rb/fix-linux-stack.pl over the output.  And probably also the --depth=12 argument (since the default of 6 is often a little low).  Despite that error, I'm still a little disappointed that this was relanded without anybody attempting to do this.

And I'd also note that the TLD service itself was not leaking, since it didn't show up in the RLk test logs.
Comment 293 :Gavin Sharp [email: gavin@gavinsharp.com] 2007-06-28 06:58:44 PDT
Thanks for investigating the leak, dbaron. My fault for not running the leak test again before checkin, and misunderstanding the leak in the first place (the Lk/Rlk disparity should have told me that my attempted fix wouldn't work, as you say). I thought I'd identified and fixed the problem and figured checking it back in would be faster than running the test myself. I didn't have access to a fast Linux machine (my VM takes quite a while to run a build with trace-malloc enabled) and wasn't familiar with trace-malloc itself (that --use-address tip is what I was looking for last night). Anyhow, no excuses - I know more now about leak debugging than I did before.
Comment 294 Dão Gottwald [:dao] 2007-06-30 15:36:34 PDT
Created attachment 270450 [details] [diff] [review]
enable binding, disable effective domain detection

We can move on even without effectiveTLDService, no?
I just hope it was the only culprit.
Comment 295 Dão Gottwald [:dao] 2007-06-30 15:45:20 PDT
Created attachment 270451 [details] [diff] [review]
enable binding, disable effective domain detection

oops. messed up the comment in browser.css.
Comment 296 :Gavin Sharp [email: gavin@gavinsharp.com] 2007-06-30 21:31:51 PDT
Comment on attachment 270451 [details] [diff] [review]
enable binding, disable effective domain detection

Good idea, let's get this in and resolve this bug, and file a new bug on re-enabling the eTLD detection, dependent on bug 386154 and bug 386155. Once that bug is filed we can refer to it in the comment.

If someone gets to land this before I can they'll need to watch Txul/Ts closely to ensure that the eTLD service was indeed the sole cause of the regressions.
Comment 297 :Gavin Sharp [email: gavin@gavinsharp.com] 2007-07-03 09:51:46 PDT
Landed that patch, filed bug 386727 on re-enabling the eTLD usage.

mozilla/browser/base/content/urlbarBindings.xml 	1.10
mozilla/browser/base/content/browser.css 	1.30
Comment 298 :Gavin Sharp [email: gavin@gavinsharp.com] 2007-07-03 10:06:14 PDT
Filed bug 386741 on the Ts/Txul regressions.
Comment 299 Jeremy Morton 2007-07-21 14:16:32 PDT
Yay.  This'll teach me for not running latest nightlies all the time, and discovering retarded new things being introduced to Firefox.  Actually, by the time this was landed, it would've been too late anyway.  I'm still gonna say it, anyhow - this is a bad idea.  It will not eliminate phishing one WHIT (and I'll pay £1000 to anyone who can prove me wrong), and in the meantime it's bloody irritating and uglifies the URLbar.  Sorry, I know you had good intentions with it, but a big thumbs down from me.  It sucks.
Comment 300 Mike Pesce (:By-Tor) 2007-07-26 08:03:25 PDT
Something happened in Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a7pre) Gecko/2007072605 Minefield/3.0a7pre ID:2007072605 that caused this to regress.  I don't have a better timeframe unfortunately.
Comment 301 Jesse Ruderman 2007-07-26 14:52:30 PDT
> Something happened ...  that caused this to regress

Maybe you're just seeing the changes from bug 388135, "Location Bar formatted view: hide certain protocols, don't de-emphasize the path".
Comment 302 Marco Bonardo [::mak] (Away 6-20 Aug) 2007-08-14 01:45:30 PDT
*** Bug 305132 has been marked as a duplicate of this bug. ***
Comment 303 Dave Townsend [:mossop] 2007-11-23 05:12:43 PST
*** Bug 405099 has been marked as a duplicate of this bug. ***
Comment 304 Tracy Walker [:tracy] 2009-08-21 10:49:57 PDT
is this not covered by a unit test such as for bug 407974?
Comment 305 Tracy Walker [:tracy] 2013-08-21 11:20:11 PDT
removing ancient in-testsuite requests

Note You need to log in before you can comment on or make changes to this bug.