411963 - should we emphasize title / url in a result when we matched due to tag?

Status: VERIFIED FIXED

(Firefox :: Address Bar, defect)

Description

[(not reading, please use [e-mail] instead)]

should we emphasize title / url in a result when we matched due to tag?

for bug #406255, we now emphasized the matching text in both title and url.

but if the match is due to a tag, we are currently not emphasizing either (and instead showing the "tag" icon).

Is this still desired?  Should we also emphasize any matching text even when we have a tag match?

Maybe it is because the tag icon is on the far right, but sometimes I'm confused about why a certain site has matched.

maybe we could make the tag icon "stronger"?

note, the code that makes it so we *don't* emphasize on tag matches is here:

http://lxr.mozilla.org/seamonkey/source/toolkit/content/widgets/autocomplete.xml#1226
 
1226           // if we aren't matching any text 
1227           // (the user has clicked on the history drop down
1228           // or this result is a "tag" match, don't bold any matching text
1229           if (text == "" || type == "tag") {
1230             this._setUpDescription(this._url, url, this._urlBox.boxObject, this._urlOverflowEllipsis, -1, -1);
1231             this._setUpDescription(this._title, title, this._titleBox.boxObject, this._titleOverflowEllipsis, -1, -1); 
1232             return;
1233           }

Comment 1

[Foteos Macrides]

I've been trying it with that if statement changed, and think there are pros and cons either way.  While you are entering the tag, the changing rows in the drop menu due to the treatment of what you are entering as a query string for a history autosearch is basically chatter to be ignored.  When you finish entering the tag, what you actually want is in the row(s) at the top of the drop menu and marked by the tag icon.  Any rows beyond those are noise in this context, and indicated as such by their not having the tag icon.  My bias is to highlight anything in the titles and/or URLs which corresponds to what has been entered in the urlbar, and not try to use non-highlighting as a cue beyond use of the tag icon.  But this seems entirely an issue of personal taste.

Comment 2

[Foteos Macrides]

(In reply to comment #1)
> When you finish entering the tag, what you actually want is in the row(s)
> at the top of the drop menu and marked by the tag icon.  Any rows beyond
> those are noise in this context, and indicated as such by their not having
> the tag icon.

I should have mentioned that it's conceivable that what you entered was intended as a query string for an autosearch of history, and happened to also be a tag, in which case you do want highlighting whenever the title and/or URL contains the query string, and it would be the rows without any highlighting by virtue of having a corresponding tag but not the query string which are the noise in the drop menu.  I guess that's why my personal preference is to always highlight.

The bottom line is that a great deal including the kitchen sink is being jammed into the urlbar functionality for Fx3, and it's bound to back up now and then. :<)

Comment 3

[[:Aleksej]]

I agree that the “tag” icon should be stronger (it is gray on gray currently, compared to the yellow star on gray), if it is associated with giving the result much weight.

My description of the issue:
“when you are typing something in the location bar, it is highlighted in the results… but when it matches a tag, it stops being highlighted [nearly in any way], making it unclear what it did match, and why is was highlighted before, since the first result is [sometimes] the same”

Comment 4

[Ed Lee :Mardak]

This will be fixed by bug 407946.

Comment 6

[Ed Lee :Mardak]

This is fixed by bug 421412.

Comment 7

[Stephen Donner [:stephend] Not actively reading bugmail]

in-litmus+:

Amended https://litmus.mozilla.org/show_test.cgi?id=4680

While I'm here:

Verified FIXED using:

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9b5pre) Gecko/2008032404 Minefield/3.0b5pre

Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9b5pre) Gecko/2008032405 Minefield/3.0b5pre

-and-

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b5pre) Gecko/2008032204 Minefield/3.0b5pre