Closed Bug 564395 Opened 14 years ago Closed 14 years ago

autocomplete tab-switching misuses browser.urlbar.default.behavior

Categories

(Firefox :: Address Bar, defect)

defect
Not set
normal

Tracking

()

VERIFIED FIXED
Tracking Status
blocking2.0 --- -

People

(Reporter: elmar.ludwig, Assigned: adw)

References

Details

(Whiteboard: [switch-to-tab])

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.3a5pre) Gecko/20100424 Minefield/3.7a5pre ID:20100424030253

Bug 480350 added an additional bit to the pref browser.urlbar.default.behavior that controls what matches are displayed for autocomplete in the location bar. However, the new setting "128: tabs" (bit 7) behaves unlike all the others.

The documentation for this pref states:

> The default behavior for the urlbar can be configured to use any combination
> of the restrict or match filters with each additional filter restricting
> more (intersection). Add the following values to set the behavior as the
> default: 1: history, 2: bookmark, 4: tag, 8: title, 16: url, 32: typed,
>          64: javascript, 128: tabs
> E.g., 0 = show all results (no filtering), 1 = only visited pages in history,
> 2 = only bookmarks, 3 = visited bookmarks, 1+16 = history matching in the url

This is true for bits 0-6, but not for the "tabs" (bit 7), which doesn't actually restrict more (intersection) but instead adds additional matches to the list. From looking at the code, it seems to work like this:

- If the bit is NOT set, URLs that match all of the other criteria are used for autocomplete.

- If the bit is set, matching is done as if the bit were not set, but additional entries are generated for each match that is currently open in a tab (but see 546253).

with two special cases:

- If the value of the pref if 0, additional entries for currently open tabs are generated anyway (although the bit is not set).

- If the value of the pref is 128, autocomplete only matches currently open tabs (but see 546253). This is the only case where it actually restricts matches instead of adding extra entries.

We could update the pref documentation to reflect this, but I doubt that it is a good idea to add all this special casing to what was previously a pref with a clearly defined meaning. Maybe we should not use the existing pref at all to control tab matching (since it is orthogonal to what is actually matched in most cases) and use a new, separate pref for this?
This is also the reason why restricting matches in the URL bar does not work as expected, e.g. typing "% foo" will display only open tabs matching "foo", but "% * foo" will display all bookmarks matching "foo" (instead of only open tabs for bookmarks matching "foo").
We should fix this.
blocking2.0: --- → ?
Depends on: 564573
this could be fixed in bug 564573. Assigning to Drew for now, correct that if i'm wrong.
Assignee: nobody → adw
This should be fixed by bug 564573.  Please reopen if not.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Blocks: 570412
While the behavior is not ideal, this does not block the final release of Firefox 4.
blocking2.0: ? → -
Why would anyone want to set the filter to only show open tabs?  Wouldn't a more logical use of setting 128 be to DISABLE "Switch to tabs" where you could add each additional filter?  For instance 130 would be "Show Bookmarks, no Swith to tabs"
(In reply to comment #6)
> Why would anyone want to set the filter to only show open tabs?  Wouldn't a
> more logical use of setting 128 be to DISABLE "Switch to tabs" where you could
> add each additional filter?  For instance 130 would be "Show Bookmarks, no
> Swith to tabs"

For the same reason the feature exists, if you have a lot of tabs you can find them easily. Also since all behaviors are exclusive, doing the opposite just for one would be confusing.
You want to follow Bug 530209 probably.
Whiteboard: [switch-to-tab]
Status: RESOLVED → VERIFIED
How is this fixed?  It still behaves differently from all the other bits, just not the same as it did before.  Seems more confusing rather than less.
It's not fixed, Mozilla just likes to pretend that including broken features within the parameters of other broken features without the ability to disable them gives users some kind of choice.
@patrickjdempsey that kind of negative posts are pointless and against our Bugzilla etiquette.  Since this is a bug tracker and not a discussion forum, please avoid posting anything that does not contain useful information to fix bugs. If you dislike the decision process in Mozilla feel free to open a discussion in mozilla.governance, but please stop spamming developers.
You need to log in before you can comment on or make changes to this bug.