424192 - Highlight awesome bar matches instead of modifying their weight and decoration

Status: RESOLVED WORKSFORME

(Firefox :: Address Bar, enhancement)

Description

[Andrés Delfino]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b5pre) Gecko/2008032011 Minefield/3.0b5pre
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b5pre) Gecko/2008032011 Minefield/3.0b5pre

I think that changing the weight of the matches is wrong, because it changes how the text is presented, making it move every time you press a key.

Underline is just ugly.

We already highlight stuff when using incremental search, in the Find bar; so I used the same behavior in the address bar.

You can give it a quick try setting your userChrome.css to:

@namespace url("http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul");
@namespace html url("http://www.w3.org/1999/xhtml");

html|*.ac-emphasize-text
{
	background:		#38D878 !important;
	color:			white !important;
	font-weight:		normal !important;
	text-decoration:	none !important
}

richlistitem.autocomplete-richlistitem:hover html|*.ac-emphasize-text
{
	background:		transparent !important
}

Note that this is buggy. Most notably, neither :focus or :active matches the selected result entry, so I used hover to show you how I'd display the selected result. I use no highlighting there because, if the user went to that entry, is highly unlikely he/she won't now what the entry was for.

Also, a bug exist if you move the cursor to the first entry and type anything in the address bar: the matches look white. This is because the :focis/:active problem.

Please note that this implementation is a live mock-up and no hard-coded color should EVER be used.

Reproducible: Always

Comment 1

[Andrés Delfino]

Attachment: Screenshot, cursor is hover bug 393791

Comment 2

[Simon Bünzli]

How is this bug different than a combination of bug 409974, bug 407861 and bug 406254?

Besides, Andrés: For more nativeness, try the following:

#PopupAutoCompleteRichResult .ac-url-text:not([selected="true"]) {
    color: GrayText !important;
}
#PopupAutoCompleteRichResult html|*.ac-emphasize-text {
    color: HighlightText !important;
    background-color: Highlight !important;
    text-decoration: none !important;
    font-weight: normal !important;
}
#PopupAutoCompleteRichResult .ac-comment {
    font-size: inherit !important;
}

Comment 3

[Andrés Delfino]

(In reply to comment #2)
> How is this bug different than a combination of bug 409974, bug 407861 and bug
> 406254?

None of their summaries propose highlighting as a solution; this bug does.

> Besides, Andrés: For more nativeness, try the following:
> 
> #PopupAutoCompleteRichResult .ac-url-text:not([selected="true"]) {
>     color: GrayText !important;
> }
> #PopupAutoCompleteRichResult html|*.ac-emphasize-text {
>     color: HighlightText !important;
>     background-color: Highlight !important;
>     text-decoration: none !important;
>     font-weight: normal !important;
> }
> #PopupAutoCompleteRichResult .ac-comment {
>     font-size: inherit !important;
> }
> 

I just wanted to make something up to show the concept, tried to find color constants in the Mozilla Developer Center, but they aren't there.

http://developer.mozilla.org/en/docs/CSS:background
http://developer.mozilla.org/en/docs/CSS:color

Anyway, I'll try your modification. Nativeness | consistency rules :D

Comment 4

[Ed Lee :Mardak]

Kinda looks like attachment 301083 [details].

Comment 5

[Andrés Delfino]

Bug 406254 describes a bug.
A solution has been proposed, but no one has answered.

Bug 407944 (where attachment 301083 [details] belongs) describes a back-end change.

This /bug/ describes a solution, not a _bug_.

Still no duplicate.