browser.urlbar.richResults = false doesn't work anymore :-(

47 views
Skip to first unread message

Lars-Erik Østerud

unread,
Dec 19, 2007, 1:11:13 PM12/19/07
to
Why doesn't the "browser.urlbar.richResults = false" work anymore?

Get the new two-line fancy drop down list even with that on :-(

I though you were going to have the "browser.urlbar.richResults"
option?

Don't like the new view at all (to few lines, to messy/confusing)?
--
Lars-Erik - http://www.osterud.name - ICQ 7297605
My Firefox tweaks: http://osterud.name/firefox.html

Dave Townsend

unread,
Dec 19, 2007, 2:03:33 PM12/19/07
to
Support for the option was removed in bug 407836, you can read more
about the reasons there.

Dave

Lars-Erik Østerud

unread,
Dec 19, 2007, 2:49:03 PM12/19/07
to
Dave Townsend wrote:

> Support for the option was removed in bug 407836, you can read more
> about the reasons there.

I read it, but don't sse the logic :-(

Why couldn't the option be left for advanced users?

FF gets more and more like IE7, easy small functional things and
posibility to choose is replaces by huge icons, eye-candy, fancy lists
etc.

That would have been OK if one could choose not to use then,
but when that is removed as well :-(

Don't like it :-(

Foteos Macrides

unread,
Dec 19, 2007, 3:15:18 PM12/19/07
to

Lars-Erik Řsterud wrote:
> I read it, but don't see the logic :-(

The "logic" for ignoring criticisms such as yours is expressed in Bug
#403159 Comment #11

Fote
--


Lars-Erik Østerud

unread,
Dec 19, 2007, 3:30:39 PM12/19/07
to
Foteos Macrides wrote:

> The "logic" for ignoring criticisms such as yours is expressed in Bug
> #403159 Comment #11

Like "use an add-on"?

Why couldn't plain and easy stuff be left as options, instead of
forcing users to write and install add-ons to make things simpler?

FF is a good browser, and FF3 too, but now after the new HUGE icons
(IE7 style) and removal of a fast, small a working drop-down, well...

I think I'm not alone in my views... Why not ask the users first?

Foteos Macrides

unread,
Dec 19, 2007, 3:59:37 PM12/19/07
to
Lars-Erik Řsterud wrote:
> I think I'm not alone in my views...

You most definitely are not alone. See:

http://groups.google.com/group/mozilla.dev.apps.firefox/browse_thread/thread/377bf39d900047e0/4b5745a1e51e9a72?lnk=gst&q=foteos+macrides#4b5745a1e51e9a72

Fote
--

Justin Dolske

unread,
Dec 19, 2007, 5:40:21 PM12/19/07
to
Lars-Erik Řsterud wrote:

> Why couldn't plain and easy stuff be left as options, instead of
> forcing users to write and install add-ons to make things simpler?

Because one of Firefox's principles is to NOT add a zillion options in
attempt to please everybody.

I was initially concerned about the new url autocomplete-menu format,
too. It took a little time to adjust to, but I think it's a clear win now.

Justin

Axel Hecht

unread,
Dec 19, 2007, 6:19:22 PM12/19/07
to

Just as an arbitrary data point, I'm not. Right now, it's still in the
way of me getting to the locations I want. I type in, forcing me to
ignore the suggestions, and then at some point, I take a deep breath,
and start investigating what's displayed.

Axel

Mike Beltzner

unread,
Dec 19, 2007, 7:32:19 PM12/19/07
to Axel Hecht, dev-apps...@lists.mozilla.org
On 19-Dec-07, at 6:19 PM, Axel Hecht wrote:

> Just as an arbitrary data point, I'm not. Right now, it's still in the
> way of me getting to the locations I want. I type in, forcing me to
> ignore the suggestions, and then at some point, I take a deep breath,
> and start investigating what's displayed.

Is that the matching algorithm or the display?

I find your arbitrary data point interesting (and saddening) but not
particularly useful in helping me understand what aspect of the design
is getting in your way. I crave more detailed introspection!

cheers,
mike

Martijn

unread,
Dec 19, 2007, 7:43:55 PM12/19/07
to Justin Dolske, dev-apps...@lists.mozilla.org
On 12/19/07, Justin Dolske <dol...@mozilla.com> wrote:

> Lars-Erik Østerud wrote:
>
> > Why couldn't plain and easy stuff be left as options, instead of
> > forcing users to write and install add-ons to make things simpler?
>
> Because one of Firefox's principles is to NOT add a zillion options in
> attempt to please everybody.

There was a pref for it, not an option.

Regards,
Martijn

> I was initially concerned about the new url autocomplete-menu format,
> too. It took a little time to adjust to, but I think it's a clear win now.
>
> Justin

> _______________________________________________
> dev-apps-firefox mailing list
> dev-apps...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-apps-firefox
>


--
Martijn Wargers - Help Mozilla!
http://weblogs.mozillazine.org/qa/
http://wiki.mozilla.org/Mozilla_QA_Community
irc://irc.mozilla.org/qa - /nick mw22

Seth Spitzer

unread,
Dec 19, 2007, 8:38:26 PM12/19/07
to
Lars-Erik,

> Like "use an add-on"?

Yes, that is much better than having a pref, as it prevents code bloat.

I've created an add-on to switch back to the Firefox 2 style, see
https://bugzilla.mozilla.org/attachment.cgi?id=293973

I'll be moving that to addons.mozilla.org

-Seth

Seth Spitzer

unread,
Dec 19, 2007, 8:38:16 PM12/19/07
to Lars-Erik Østerud
Lars-Erik,

> Like "use an add-on"?

Yes, that is much better than having a pref, as it prevents code bloat.

Seth Spitzer

unread,
Dec 19, 2007, 8:52:39 PM12/19/07
to
> I'll be moving that to addons.mozilla.org

https://addons.mozilla.org/en-US/firefox/addon/6227

Currently in the amo sandbox.

-Seth

Foteos Macrides

unread,
Dec 19, 2007, 10:34:30 PM12/19/07
to
Seth Spitzer wrote:
> https://addons.mozilla.org/en-US/firefox/addon/6227
> Currently in the amo sandbox.

Thank you, Seth, for making this add-on available yourself as part of the
fix for Bug #407836.

It works with tonight's Minefield, but not with yesterday's Fx3.0b2 release,
even though it's indicated as working with Firefox: 3.0b2pre – 3.0b3pre

Am I mis-understanding what that version span means?

Fote
--

Seth Spitzer

unread,
Dec 20, 2007, 1:24:39 AM12/20/07
to Foteos Macrides
Foteos,

> It works with tonight's Minefield, but not with yesterday's Fx3.0b2 release,
> even though it's indicated as working with Firefox: 3.0b2pre – 3.0b3pre

Good catch.

With 3.0b2, you can still use the browser.urlbar.richResults pref.

I'll fix the add on to only work with 3.0b3pre.

-Seth

Lars-Erik Østerud

unread,
Dec 20, 2007, 2:03:14 AM12/20/07
to
URL autocomplete suggestion:

Instead of marking the matches with BOLD + underline (looks a bit ugly
I think), how about marking it with a different background color -
just like with "find" ?

Axel Hecht

unread,
Dec 20, 2007, 8:06:50 AM12/20/07
to

I think there are two aspects. Probably most prominently, I'm surfing
via URLs, and those get de-emphasized. So I need to look harder to
actually find what I know. The second piece that I find disturbing is
that there seems to be a concurrence between me actually consiously
scanning the suggestions and some timeout that gives me more hits. That
is, as soon as I start reading, the list changes.

I'm having a "too much data" problem, too, I guess. That might come from
not seeding it enough, or the search not being good enough yet. Just
played with it, http://flickr.com/photos/axelhecht/2124897766/, for
"bug", 2 out of 10 links have useful data in the display. It took me a
bit to figure out that the litmus links are in there because those
queries have a "withbugs=all" query param in them.

Oh, and are we going to release note "use a different profile for porn"? ;-)

Axel

Mike Beltzner

unread,
Dec 20, 2007, 8:51:44 AM12/20/07
to Axel Hecht, dev-apps...@lists.mozilla.org
On 20-Dec-07, at 8:06 AM, Axel Hecht wrote:

> Mike Beltzner wrote:
>> On 19-Dec-07, at 6:19 PM, Axel Hecht wrote:
>>
>>> Just as an arbitrary data point, I'm not. Right now, it's still in
>>> the
>>> way of me getting to the locations I want. I type in, forcing me to
>>> ignore the suggestions, and then at some point, I take a deep
>>> breath,
>>> and start investigating what's displayed.
>>
>> Is that the matching algorithm or the display?
>>
>> I find your arbitrary data point interesting (and saddening) but not
>> particularly useful in helping me understand what aspect of the
>> design
>> is getting in your way. I crave more detailed introspection!
>>
>
> I think there are two aspects. Probably most prominently, I'm surfing
> via URLs, and those get de-emphasized. So I need to look harder to
> actually find what I know. The second piece that I find disturbing is
> that there seems to be a concurrence between me actually consiously
> scanning the suggestions and some timeout that gives me more hits.
> That
> is, as soon as I start reading, the list changes.

OK, I've heard this before, and am working on some ideas to see if we
can make it easier to see the URLs. The design goal here is actually
to make it easier to pick URLs out from this list (since one can see
more of them than before, and they are painted green, as they are in
search results) so it's certainly not good that we're interfering with
that.

> I'm having a "too much data" problem, too, I guess. That might come
> from
> not seeding it enough, or the search not being good enough yet. Just
> played with it, http://flickr.com/photos/axelhecht/2124897766/, for
> "bug", 2 out of 10 links have useful data in the display. It took me a
> bit to figure out that the litmus links are in there because those
> queries have a "withbugs=all" query param in them.

As far as I can tell, that would happen the same way with the less
rich results, the only difference being that you might not be able to
see the matching part of the URL because part of the horizontal space
would be given to a snippet of the page title.

Not matching against query params is an interesting optimization,
though; I think we considered it, but realized that sometimes it would
be useful.

> Oh, and are we going to release note "use a different profile for
> porn"? ;-)

We never have before, I don't see why we'd start now. :)

cheers,
mike

Michael Lefevre

unread,
Dec 20, 2007, 9:45:39 AM12/20/07
to
On 2007-12-20, Mike Beltzner <belt...@mozilla.com> wrote:
> On 19-Dec-07, at 6:19 PM, Axel Hecht wrote:
>
>> Just as an arbitrary data point, I'm not. Right now, it's still in the
>> way of me getting to the locations I want. I type in, forcing me to
>> ignore the suggestions, and then at some point, I take a deep breath,
>> and start investigating what's displayed.
>
> Is that the matching algorithm or the display?

As another arbitrary data point, I have the beta installed on my computer
at home, and a friend's first reaction on seeing the new drop down was
that the huge text was some sort of accessibility feature for people that
couldn't read normal size text. I agree that the larger-than-normal text
looks a bit weird and clunky.

As for the matching algorithm - it seems pretty good, but is not so great
when you've only typed 1 or 2 letters, so I wonder if flashing up a whole
load of stuff is useful enough to counter the rather distracting effect of
it.

Going in the other direction from simplicity, I feel there is some merit
in Daniel Glazman's thoughts about customisation -
http://www.glazman.org/weblog/dotclear/index.php?post/2007/12/20/Firefox-3b2-address-bar
Quite often I do actually know whether I want a site that I've visited a
lot or a site that I've visited recently or something that I've previously
bookmarked. If, when faced with a lot of results, I could somehow tweak
the matching as I go (by doing something more than typing more letters to
be a found together), that might be good. But I guess that is something
for an extension...

--
Michael

Adam Kowalczyk

unread,
Dec 20, 2007, 10:41:42 AM12/20/07
to
Michael Lefevre wrote:
> Going in the other direction from simplicity, I feel there is some merit
> in Daniel Glazman's thoughts about customisation -
> http://www.glazman.org/weblog/dotclear/index.php?post/2007/12/20/Firefox-3b2-address-bar
> Quite often I do actually know whether I want a site that I've visited a
> lot or a site that I've visited recently or something that I've previously
> bookmarked. If, when faced with a lot of results, I could somehow tweak
> the matching as I go (by doing something more than typing more letters to
> be a found together), that might be good. But I guess that is something
> for an extension...

Edward Lee is working on what he calls "adaptive learning"[1] which
accomplishes exactly what you are asking for. As far as I know, it is
scheduled to be included in Firefox 3.

- Adam


[1] https://bugzilla.mozilla.org/show_bug.cgi?id=395739

Mike Beltzner

unread,
Dec 20, 2007, 11:18:36 AM12/20/07
to Adam Kowalczyk, dev-apps...@lists.mozilla.org
Adam Kowalczyk wrote:
> Michael Lefevre wrote:
> > Going in the other direction from simplicity, I feel there is some merit
>> in Daniel Glazman's thoughts about customisation -
>> http://www.glazman.org/weblog/dotclear/index.php?post/2007/12/20/Firefox-3b2-address-bar
>> Quite often I do actually know whether I want a site that I've visited a
>> lot or a site that I've visited recently or something that I've previously
>> bookmarked. If, when faced with a lot of results, I could somehow tweak
>> the matching as I go (by doing something more than typing more letters to
>> be a found together), that might be good. But I guess that is something
>> for an extension...

I've heard a lot of people ask for deep customization here, but I think
that's best for extension fodder at the moment. We've been working hard
to keep the performance impact down to a minimum, and it feels like
adding these alternate paths might affect that. Seth might know more.

I will be posting to my blog today or tomorrow with some userChrome.css
hacks that people can use to change the colours, though, so that we can
get some alternate ideas generated.

I do, otoh, like Daniel's idea for Shift-Delete removing a single item
from the history; anyone know if there's a bug on that?

>
> Edward Lee is working on what he calls "adaptive learning"[1] which
> accomplishes exactly what you are asking for. As far as I know, it is
> scheduled to be included in Firefox 3.
>
> - Adam
>
> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=395739

Indeed, changes to the matching algorithms are in the works, and I think
there's a lot more we can do to make sure that the intelligent results
are truly intelligent.

cheers,
mike

Lars-Erik Østerud

unread,
Dec 20, 2007, 12:40:49 PM12/20/07
to
> OK, I've heard this before, and am working on some ideas to see if we
> can make it easier to see the URLs. The design goal here is actually
> to make it easier to pick URLs out from this list (since one can see

Enabling the old style with an option to not display the "title"
would do that (a plain drop-down with the icon and the URL - no more).

Make it an option somewhere.

I had allready in my "userChrome.css" for 2.0 made the "title" field
narrower (you can even remove it), and I have found a way to remove
the "title" and adjust the position of the URL in the "rich list" as
well using "userChrome.css" (and negative margins and stuff).

So if you don't include these options, they will still be there,
but harder to get (more tech knowledge) for the non-tech users.

Lars-Erik Østerud

unread,
Dec 20, 2007, 12:42:11 PM12/20/07
to
Michael Lefevre wrote:

> As another arbitrary data point, I have the beta installed on my computer
> at home, and a friend's first reaction on seeing the new drop down was

How will this new two-line complicated drop-down work for those using
tools for blind (reading lists) or poor-sight (high contrast, huge
font). I would think the old style was much better for those?

Mike Beltzner

unread,
Dec 20, 2007, 12:52:23 PM12/20/07
to dev-apps...@lists.mozilla.org
Lars-Erik Řsterud wrote:
> Make it an option somewhere.

Adding an option is not free; it adds code bloat and creates additional
testing paths, and in cases where the option is user facing, it adds
information that the user must parse when looking for a certain
preference or option that they actually care about.

So far I haven't heard a convincing argument about why this needs to be
an option as opposed to an add-on.

> I had allready in my "userChrome.css" for 2.0 made the "title" field
> narrower (you can even remove it), and I have found a way to remove
> the "title" and adjust the position of the URL in the "rich list" as
> well using "userChrome.css" (and negative margins and stuff).
>
> So if you don't include these options, they will still be there,
> but harder to get (more tech knowledge) for the non-tech users.

Non-tech users don't care about URLs as much as they care about page titles.

cheers,
mike

Adam Kowalczyk

unread,
Dec 20, 2007, 1:29:48 PM12/20/07
to Mike Beltzner
Mike Beltzner wrote:
> Non-tech users don't care about URLs as much as they care about page
> titles.

I don't think that's strictly true, FWIW. I would agree that they don't
usually understand the entire structure of URLs. However, they are
certainly familiar with domains, nowadays when many printed adverts
include website addresses and the phrase "visit goats-insurance dot com"
attacks us a dozen times a day. I see plenty of people calling websites
by their domains. I suppose this happens especially in cases of websites
which don't have clear, memorable, or concise names, which makes it
easier to just use their domains instead.

Based on these observations, I think that non-tech users type domains in
their Location Bars all the time.

- Adam

Axel Hecht

unread,
Dec 20, 2007, 7:32:15 PM12/20/07
to
Mike Beltzner wrote:
> Lars-Erik Řsterud wrote:
>> Make it an option somewhere.
>
> Adding an option is not free; it adds code bloat and creates additional
> testing paths, and in cases where the option is user facing, it adds
> information that the user must parse when looking for a certain
> preference or option that they actually care about.
>
> So far I haven't heard a convincing argument about why this needs to be
> an option as opposed to an add-on.

I'm not convinced that putting the blame on an extension author is
helping here. If QA tests an option or if QA tests another overly
popular extension is probably a loose-loose situation.

Anyway, from what I see, there's data that indicates that the awesomebar
needs work, and there are bugs open to work on it. I would think that
there are likely some scenarios to be looked at and designed for in this
thread, and I just rest assured that that's happening. The wording in
the last half-sentence is wrong, but I wouldn't even have some German
for beltzner here in my head right now.

I think that Firefox is about coming up with the most usable solution
beneficial to a large audience, laying ground for extensions to cover
niches. I don't think the awesomebar is there yet. It's currently
showing everything that could be relevant and of interest, and not
showing what's of interest while giving an opportunity to go beyond.

Again, I'm sure that some mix of brains, cookies and punch will get us
ahead here, and if anything else fails, the UX team can still shave :-)

Axel

Lars-Erik Østerud

unread,
Dec 21, 2007, 5:03:04 AM12/21/07
to
> Adding an option is not free; it adds code bloat and creates additional
> testing paths, and in cases where the option is user facing, it adds

Given how easy it is to add the "old-style" url-auto-complete I guess
the code is not huge. And the old-style auto-complete is used other
places. Also it was there, was tested, worked. You even added an
option to use the old one in "about:config". Then why remove it again?

> Non-tech users don't care about URLs as much as they care about page titles.

I my world, we only use URLs. Title are useless (very often) over here

Lars-Erik Østerud

unread,
Dec 21, 2007, 5:04:06 AM12/21/07
to
Adam Kowalczyk wrote:

> Based on these observations, I think that non-tech users type domains in
> their Location Bars all the time.

Second that. Have NEVER seens any of my friends (very non-tech) use
anything other than URL. Most don't even know that is possible :-)

Michiel van Leeuwen

unread,
Dec 21, 2007, 11:38:36 AM12/21/07
to
Mike Beltzner wrote:
> Non-tech users don't care about URLs as much as they care about page
> titles.

So non-tech users have to ignore every other line (the one with the url)
while scanning the list. Users that prefer url's have to do the same. To
me, that sounds non-optimal in both cases. Having the title and the url
in two columns would make it easier for both.

Michiel

Mike Beltzner

unread,
Dec 21, 2007, 11:55:56 AM12/21/07
to Michiel van Leeuwen, dev-apps...@lists.mozilla.org
Michiel van Leeuwen wrote:
> So non-tech users have to ignore every other line (the one with the url)
> while scanning the list. Users that prefer url's have to do the same. To
> me, that sounds non-optimal in both cases. Having the title and the url
> in two columns would make it easier for both.

Except for the part where you can't read either since they're both clipped.

cheers,
mike

Foteos Macrides

unread,
Dec 21, 2007, 1:32:41 PM12/21/07
to
>> Non-tech users don't care about URLs as much as they care about page
>> titles.
>
> I my world, we only use URLs. Title are useless (very often) over here
> --
> Lars-Erik - http://www.osterud.name - ICQ 7297605
> My Firefox tweaks: http://osterud.name/firefox.html

Lars-Erik,

I suspect that much of this debate might become moot if it weren't for those
titles in Fx3.0b2 and Minefield screaming at you and making it difficult to
focus on the URLs.

Since your site is already offering add-ons, and you earlier indicated that
you had been able to change the formatting in the "rich list" using
userChrome.css, it might be useful to gather some empirical data. How about
offering an add-on which makes the titles the same font-size as the URLs
(still with color:black versus color:green) and valigns the shortcut icon
with respect to both lines so that it doesn't necessitate a greater
line-height for the titles. Perhaps you could also provide a screen-shot
with that formatting as an attachment in Bug 406215.

We might then conduct a survey with questions such as:

1. Which format do you prefer?
2. Are you a so-called "non-tech" or "not non-tech" person?
3. If a "non-tech" person, have you nonetheless learned enough about URL
structure to pay attention to URLs for protection against phishing and
identity theft?
4. Have you noticed that in Google hit lists, the titles have a larger
font-size than the URLs, but they are never opposed, and instead always have
color:black text with the same font-size as the color:green URLs interposed?
5. Do you think it would be unfortunate if the formatting of the urlbar
dropdown in Fx3.0b2 and the current Minefield, and the so-called "need to
get used to it" interfered with a broader appreciation of the Fx3+
autocomplete and all the work which the Fx developers put into it?

Fote
--


Lars-Erik Østerud

unread,
Dec 21, 2007, 2:35:28 PM12/21/07
to
Foteos Macrides wrote:

> I suspect that much of this debate might become moot if it weren't for those
> titles in Fx3.0b2 and Minefield screaming at you and making it difficult to
> focus on the URLs.

Also I have tweaked a little to make it fit more into my "look":

/* FF3 URL-dropdown */
richlistitem spacer,richlistitem label{display:none!important}
.ac-title{margin:-4px 8px 2px -4px!important}
.ac-url{margin:-6px 0px 0px 20px!important}

Would be nice combining the best of the old and the new look !!!
BTW: The search highlight with bold+ul does not look good :-(

> offering an add-on which makes the titles the same font-size as the URLs
> (still with color:black versus color:green) and valigns the shortcut icon
> with respect to both lines so that it doesn't necessitate a greater

I have been thinking about setting down the font-size in
"userChrome.css", but fear that will not work OK with different
Windows font settings (as you have to set a fixed size).

I'm thinking of moving both back on one line with some CSS entries,
getting the old look back, but WITH the search-highlight (and without
the lines between each entry). I'll experiment some more :-)

> We might then conduct a survey with questions such as:

I'm all in favour of surveys.

I think to many programs (like MS Vista and the new Office suits) are
to much designed for the casual user, and not for the "mass"-user
(those that work with IT all day - the new UIs are annoying for us).

Lars-Erik Østerud

unread,
Dec 21, 2007, 2:36:44 PM12/21/07
to
Mike Beltzner wrote:

> Except for the part where you can't read either since they're both clipped.

But screens get wider and wider, and with the ability to search from
the URLbar maybe the search-bar is not for any use. Then you have
width to use...

Lars-Erik Østerud

unread,
Dec 21, 2007, 3:17:13 PM12/21/07
to
I tried this, and it looks quite OK (try it and see :-):

richlistitem spacer,richlistitem label{display:none!important}

richlistitem{border:none!important}
.ac-title{margin:-4px 0px 0px
300px!important;background:solid!important}
.ac-title
description{font-size:11px!important;color:ThreeDShadow!important}
.ac-title description[selected="true"]{color:white!important}
.ac-url{margin:-19px 0px 0px 20px!important}
.ac-url description{color:black!important}
.ac-url description[selected="true"]{color:white!important}

BUT I have trouble with the width of the "title" and "url".
No matter what attibute I set the width is not restricted.
And then the text overlap each other, not looking good :-(

Also I have to set a fixed startpoint for the "title" (300px).
A variable one (a percantage) would be better to suit more screens

Mike Beltzner

unread,
Dec 21, 2007, 3:41:02 PM12/21/07
to dev-apps...@lists.mozilla.org
Lars-Erik Řsterud wrote:
> I tried this, and it looks quite OK (try it and see :-):
>
> richlistitem spacer,richlistitem label{display:none!important}
> richlistitem{border:none!important}
> .ac-title{margin:-4px 0px 0px
> 300px!important;background:solid!important}
> .ac-title
> description{font-size:11px!important;color:ThreeDShadow!important}
> .ac-title description[selected="true"]{color:white!important}
> .ac-url{margin:-19px 0px 0px 20px!important}
> .ac-url description{color:black!important}
> .ac-url description[selected="true"]{color:white!important}
>
> BUT I have trouble with the width of the "title" and "url".
> No matter what attibute I set the width is not restricted.
> And then the text overlap each other, not looking good :-(
>
> Also I have to set a fixed startpoint for the "title" (300px).
> A variable one (a percantage) would be better to suit more screens

Thanks for playing around with the settings, Lars. That's helpful. For
people who might not know how to play with userChrome.css, can you also
put out screenshots?

cheers,
mike

Foteos Macrides

unread,
Dec 21, 2007, 4:05:51 PM12/21/07
to
Lars-Erik Řsterud wrote:
> Would be nice combining the best of the old and the new look !!!
> BTW: The search highlight with bold+ul does not look good :-(

> I'm thinking of moving both back on one line with some CSS entries,


> getting the old look back, but WITH the search-highlight (and without
> the lines between each entry). I'll experiment some more :-)

Seth's oldbar add-on meets my basic need for an easy way to switch between
the new default, vertically-stacked format and a compact, horizontal format
which lets me focus unencumbered on the URLs. Since it does retain the
autocomplete, I guess it would be nice to also have the search-highlight.
But that's not a big issue for me, personally, and I'll remain content if
Seth simply keeps updating the version restriction and does any necessary
tweaking of it for successive releases.

I completely agree with you, though, that the bold+ul is inadequate, and it
would be much better to make that the same as for "Highlight all" in the
Find searches. But some outstanding bugs indicate that efficiency and RTL
issues still need to be overcome.

Fote
--


Lars-Erik Østerud

unread,
Dec 21, 2007, 5:12:52 PM12/21/07
to
> richlistitem spacer,richlistitem label{display:none!important}
> richlistitem{border:none!important}
> .ac-title{margin:-4px 0px 0px 300px!important;background:solid!important}
> .ac-title description{font-size:11px!important;color:ThreeDShadow!important}
> .ac-title description[selected="true"]{color:white!important}
> .ac-url{margin:-19px 0px 0px 20px!important}
> .ac-url description{color:black!important}
> .ac-url description[selected="true"]{color:white!important}

Here is the screenshot for the code above:
http://osterud.name/RichBar1.png

If anyone can help with how to restrict the width of the text
so it does not overlap each other or the "star" icon, please tell me


> richlistitem spacer,richlistitem label{display:none!important}

> .ac-title{margin:-4px 8px 2px -4px!important}
> .ac-url{margin:-6px 0px 0px 20px!important}

And here is the compacted version of the two-line display
by the code above: http://osterud.name/RichBar2.png


Both are adjusted so that margins and stuff fits with the tweaked
menu/urlbar in the userChrome.css at http://osterud.name/firefox.html

Dave Townsend

unread,
Dec 21, 2007, 5:31:41 PM12/21/07
to
Lars-Erik Řsterud wrote:
> Mike Beltzner wrote:
>
>> Except for the part where you can't read either since they're both clipped.
>
> But screens get wider and wider, and with the ability to search from
> the URLbar maybe the search-bar is not for any use. Then you have
> width to use...

Numbers vary depending on exactly where you get your stats from of
course, but 1024x768 is still the most popular screen size on the web.
Apparently nearly 1 in 7 users are still on 800x600. Heck if you're
talking physical monitor size, mine hasn't changed in around 7 years :(

Dave

Lars-Erik Østerud

unread,
Dec 21, 2007, 5:36:41 PM12/21/07
to
Dave Townsend wrote:

> Numbers vary depending on exactly where you get your stats from of
> course, but 1024x768 is still the most popular screen size on the web.
> Apparently nearly 1 in 7 users are still on 800x600. Heck if you're
> talking physical monitor size, mine hasn't changed in around 7 years :(

Of course I know :-) That why I have made the "minimized" userChrome

But still. I think that even at 1024x768 the old style dropdown is OK

IF you can loose the searchbar (you can search from the urlbar so it's
not really any need for it anymore, right), then you have even more

Foteos Macrides

unread,
Dec 21, 2007, 5:56:05 PM12/21/07
to
Lars-Erik Řsterud wrote:
> And here is the compacted version of the two-line display
> by the code above: http://osterud.name/RichBar2.png

That's an improvement over the current spaciness. The shortcut icon drops
down to overlap with the URL and visually ties it with the title so that you
don't need the horizontal lines, which also interfere with scanning the
list. If the title could be made to have the same font-size as the URL then
that would work out yet better.

Fote
--


Foteos Macrides

unread,
Dec 21, 2007, 6:54:28 PM12/21/07
to
Lars-Erik Řsterud wrote:
> IF you can loose the searchbar (you can search from the urlbar so it's
> not really any need for it anymore, right), then you have even more

Hmm... I thought that the autocomplete urlbar search is of copy-and-pasted
URLs plus other available browsing history, and one's bookmarks, whereas the
searchbar is for a search-engine's database of the entire web (or as much of
it as the engine has walked). These are fundamentally different and both
desired. It's true that many users enter "domains" in the searchbar (NOT
titles, but the host field of a URL) for a "quick" link to a frequented
site, and the urlbar search can do that more quickly. Otherwise the urlbar
and searchbar are not interchangeable, but correct me if I'm wrong.

For Fx3 there is a slidebar-handle between the urlbar and searchbar, so you
can quickly change their relative widths, if needed, depending on which one
you are using. In Fx2 I moved the searchbar up, so that the urlbar can fill
the entire width of the window. There was some bogus discussion earlier
about that in relation to bar heights and inferred platform conventions, but
I use the small icons without text, and the bar heights are just fine and
dandy (plus being unconventional doesn't bother me :<). You can still do
that with Fx3 if you should find its slidebar-handle feature inadequate.

Fote
--


Lars-Erik Østerud

unread,
Dec 21, 2007, 6:59:06 PM12/21/07
to
> That's an improvement over the current spaciness. The shortcut icon drops
> down to overlap with the URL and visually ties it with the title so that you
> don't need the horizontal lines, which also interfere with scanning the
> list. If the title could be made to have the same font-size as the URL then

Looks weird without the horizontal lines with two line model :-(

Here's an image of this code:

richlistitem spacer,richlistitem label{display:none!important}
richlistitem{border:none!important}

.ac-title{margin:-7px 8px 2px -4px!important}
.ac-title description{font-size:11px!important}
.ac-url{margin:-8px 0px 0px 20px!important}

With and without the horizontal lines:

URL: http://osterud.name/RichBar3.png

Foteos Macrides

unread,
Dec 21, 2007, 7:43:12 PM12/21/07
to
Lars-Erik Řsterud wrote:
> Looks weird without the horizontal lines with two line model :-(
>
> Here's an image of this code:

> With and without the horizontal lines:
>
> URL: http://osterud.name/RichBar3.png

Oh wow!!! I love it with the same font-sizes and no horizontal lines. I
know what I'm looking for in such lists, and I can scan for it much more
quickly that way, then scroll down to it when I have that hit.

Can you make that a standard add-on and put it in the sandbox so I can use
it as the complement for Seth's oldbar add-on (or do I have to figure out
how to create add-ons myself :<)?

BTW, though you have indicated that you would prefer an Option solution for
this issue, with the Fx3 Add-ons Menu, which has a Disable/Enable button for
each entry, plus a Find Updates button and a Restart Browser button at the
bottom, it is much faster and easier to change the behavior than if one has
to plow through a set of Options Menus.

Of course, if the Add-ons entries increase to encompass as many choices as
the Options Menus do . . .

Fote
--


Lars-Erik Østerud

unread,
Dec 21, 2007, 7:46:54 PM12/21/07
to
Foteos Macrides wrote:

> Can you make that a standard add-on and put it in the sandbox so I can use
> it as the complement for Seth's oldbar add-on (or do I have to figure out

I'm no good with add-ons, only with userChrome.css hacks :-/

But if you cut the code from the message, save it as "userChrome.css"
and put it in the "CHROME" folder inside the profile folder, then...

> BTW, though you have indicated that you would prefer an Option solution for
> this issue, with the Fx3 Add-ons Menu, which has a Disable/Enable button for
> each entry, plus a Find Updates button and a Restart Browser button at the
> bottom, it is much faster and easier to change the behavior than if one has
> to plow through a set of Options Menus.

yes, but as I said, I have no experience in making add-ons (yet) :-(

Lars-Erik Østerud

unread,
Dec 21, 2007, 7:53:42 PM12/21/07
to
> Hmm... I thought that the autocomplete urlbar search is of copy-and-pasted
> URLs plus other available browsing history, and one's bookmarks, whereas the

Try typing a search critera in the URL-bar and hit enter.
Here that launches the search page with that search-critera.
But I don't know if that is enabled as default
(I have added som "user.js" settings that might do something).

Anyway, it IS possible to set it up to serch from the URL-bar.
And here it works like this..

1) when you start typing you get the auto-complete list with
the matches in the URL and TITLE, and can click on one of
them, or....

2) Just press enter to search for the phrase using the search-engine
(now, if the phrase is just one word the default is to add
"http://" so it must have a space, or you must alter some setting)

But why have two fields if one is enough?

> For Fx3 there is a slidebar-handle between the urlbar and searchbar, so you
> can quickly change their relative widths, if needed, depending on which one

I know, had a bit if trouble making that look good in my "userChrome"
tweak :-) But I thing the result got OK so far. It's a neat addition

Frank

unread,
Dec 21, 2007, 8:00:48 PM12/21/07
to
On Dec 20, 5:42 pm, Lars-Erik Østerud <.@.> wrote:

> How will this new two-line complicated drop-down work for those using
> tools for blind (reading lists) or poor-sight (high contrast, huge
> font). I would think the old style was much better for those?
> --
> Lars-Erik - http://www.osterud.name - ICQ 7297605
> My Firefox tweaks:http://osterud.name/firefox.html

Hi Lars-Erik, this two-line dropdown will work fine for the visually
disabled. Although not visually impaired myself, I'm the guy that made
the Metal Lion HiViz Sidebar for the visually disabled and I see no
problem here.

The point, it seems to me, that many here are missing is this. If you
have a single line, limited to the width of the urlbar, then both
entries on that line need to be truncated (shortened) to fit. This
makes those 2 entries useless to anyone who uses an even remotely
narrow urlbar width. The url address shown is particularly useless
when truncated. I want to stress this point again - the dropdown is
useless in that format, people cannot read the full bookmark name and
certainly cannot read most of an url address. It is a total waste of
space like that, visually impaired or otherwise.

However, the richlist 2 line system not only shows more of those
entries on an urlbar of the same width proportion as above, but also
readily lends itself to being able to untruncate both line entries
outside the width of the urlbar, where they may be viewed in full, if
required, with the addition of a horizontal scrollbar. Not just one
pair of entries, but all of them. You then have a dropdown that
actually achieves some functionality.

Frank

unread,
Dec 21, 2007, 8:37:02 PM12/21/07
to
On Dec 21, 10:03 am, Lars-Erik Østerud <.@.> wrote:

> I my world, we only use URLs. Title are useless (very often) over here

It takes about 30 seconds for a themer to write the code for the 2
line entry text, in any combination of px size or colour.

By default, my own stuff gives priority to the entry Title, in terms
of colour, font-weight and px size. One single line in userChrome.css
could then turn that priority to the Url address if necessary,
whatever the user preferred. I suppose someone could even bring out an
extension with a single line of css to do it.

We ain't exactly talking no complicated coding here. :)

Foteos Macrides

unread,
Dec 21, 2007, 8:37:39 PM12/21/07