607894 - Tab matches always appear before normal history results

Status: RESOLVED FIXED

(Toolkit :: Places, defect)

Description

[Ed Lee :Mardak]

Currently tab matches will always show up first in suggestions. This means if you have multiple tabs open to random pages for some site then try visiting a high-frecency page, it might not show up as the tab entries push it down.

Not sure if this was an intended change with bug 546253. Marked regression from the original intent of inserting switch-to-tab for history results that happen to be open in a tab.

These lines in particular cause this regression:
http://hg.mozilla.org/mozilla-central/rev/469328928474#l4.80

-      [this._getBoundAdaptiveQuery(), query];
+      [this._getBoundAdaptiveQuery(), this._getBoundOpenPagesQuery(), query];

This will cause adaptive results to show up first then tab results then all other results.

Comment 1

[Marco Bonardo [:mak]]

there was request (Also see bug 546254) that switch to tab get higher relevance in the locationbar, moving them after query would mean making them practically disappear.
I left adaptive before them because they seem more sensible to the user's specific needs.
So, if the question is regarding if that change was wanted or unnoticed, it was wanted.

Comment 2

[Marco Bonardo [:mak]]

on the other side, I think could be time to evaluate an increase of default number of suggestions from 6 to 8 and from 12 to 16

Comment 3

[Thomas Stache]

(In reply to comment #1)
> there was request (Also see bug 546254) that switch to tab get higher relevance
> in the locationbar, moving them after query would mean making them practically
> disappear.

Maybe it's just me and compounded by using Sync (see bug 597874), but tab matches almost always clog my result list, and impeding my browsing experience. I even looked for a way to disable tab matches outright the other day, as I fail to see why a list of very specific URLs like
https://wiki.mozilla.org/Firefox/Planning/2010-10-27
https://wiki.mozilla.org/Mobile/Notes/27-Oct-2010
should be useful when I input "wiki.mo" and like to go to the homepage.

Comment 4

[Thomas Stache]

Hmm, an idea just came to mind, sorry for the spam:
Could the tab matches be inserted at position 2 in the suggestion list? That would address the use case of reminding the user that he has an open tab, while leaving the top spot for "real suggestions" that I could pick immediately using the "Enter Selects" or "Speak Words" add-ons?

Comment 5

[Marco Bonardo [:mak]]

There is no position 2, if you give priority to history results they will be first and most likely make all of switches disappear (it is a much larger group too). There are already adaptive results in position 1, if sync does not sync them, that's a separate (And filed, as you said) blocker bug.
What we could do as a try, is to make _openPagesQuery return only entries that do not have an entry in moz_places and let next queries mixup things with frecency. But this would make bug 546254 a blocker again (Was unblocked based on the fact now switches come first), at that point we should add an hard to quantify bonus to openpages frecency. Unfortunately that can't be done at frecency calculation time because openpages change pretty often and per session, nor we can do it at query time, because we would throw away the SQLite index on frecency.

Comment 6

[Ed Lee :Mardak]

(In reply to comment #1)
> if that change was wanted or unnoticed, it was wanted.
Ok thanks for clarifying.

(In reply to comment #2)
> number of suggestions from 6 to 8 and from 12 to 16
What are these numbers? You're referring to maxRichResults for searching vs dropdown?

(In reply to comment #5)
> There is no position 2
Perhaps this is more for the add-on then, but perhaps one option is to make sure switch-to-tab entries aren't first by stashing them on the side until a non-switch result comes in then fill in the switch results.

Comment 7

[Marco Bonardo [:mak]]

> (In reply to comment #2)
> > number of suggestions from 6 to 8 and from 12 to 16
> What are these numbers? You're referring to maxRichResults for searching vs
> dropdown?

yep, a small increase would globally help, unless we have evidence that we can't absolutely show over than 6 results.

> (In reply to comment #5)
> > There is no position 2
> Perhaps this is more for the add-on then, but perhaps one option is to make
> sure switch-to-tab entries aren't first by stashing them on the side until a
> non-switch result comes in then fill in the switch results.

should be tested first, it's hard to guess the user's will, and looks like going to delay results a bit. Also I'm not sure it is really going to help, it would just help cases where the first result is the wanted one.

Comment 8

[Thomas Stache]

(In reply to comment #7)
> should be tested first, it's hard to guess the user's will, and looks like
> going to delay results a bit. Also I'm not sure it is really going to help, it
> would just help cases where the first result is the wanted one.

Well, this is the big promise of the awesome bar! Right now for 1-2 letter inputs tab matches always take the first position (with 10-15 open tabs, for some variety through the alphabet), which is never what I want.

Comment 9

[Dietrich Ayala (:dietrich)]

I'm really seeing the opposite of this bug with my profile. I have a ton of etherpad pages in history, and 3 open, and the two sets do not intersect. If i type "et" in the location bar, the not-open entries are shown first. That's just one example. I never use the feature, because it's almost never available to me.

Comment 10

[Thomas Stache]

Attachment: Tab match for current empty tab

For me it even started to surface the current empty tab as tab match, instead of one of my bookmarks for about:config, about:sync-log or about:crashes, that I visited an awful lot of times. But that's probably not this bug...

Comment 11

[Marco Bonardo [:mak]]

that's bug 555694.

Comment 12

[Ed Lee :Mardak]

(In reply to comment #9)
> type "et" in the location bar, the not-open entries are shown first
Those entries are likely in your adaptive history.

Components.utils.import("resource://services-sync/util.js"); Utils.queryAsync(Utils.createStatement(Svc.History.DBConnection, "SELECT * FROM moz_inputhistory JOIN moz_places ON id = place_id WHERE input LIKE 'et%'"), ["input", "url", "use_count"]).map(function(r) JSON.stringify(r)).join("\n")

Comment 13

[Dietrich Ayala (:dietrich)]

(In reply to comment #12)
> (In reply to comment #9)
> > type "et" in the location bar, the not-open entries are shown first
> Those entries are likely in your adaptive history.

Sure, but regardless of why they're not, I think the open tabs (eg: what I'm currently working with) should be ranked higher that they are. Which is the opposite of this bug :)

I'm not saying this bug is not valid, just that if we fix this bug, we need to ensure that the opposite situation doesn't get worse.

Comment 14

[Ed Lee :Mardak]

Sounds like the adaptive learning is keeping a mapping that you don't actually want. You can test it by typing ". et" (assuming you haven't typed that and selected something before). The open tab results should be showing up first.

Some reason I remember writing code that decayed these mappings faster than other unrelated mappings. E.g., if you do use "et" for one particular etherpad, anything else starting with "et" would decay. And I suppose here we would want to make sure anything under the threshold wouldn't be placed before tabs.

Comment 15

[Thomas Stache]

Tab matches are not configurable, aren't they (e.g. adjusting their frecency boost, or (de)activating the feature)? I'd be happy to just opt out of using them... That would also "fix" the issue from comment 0 (granted, brute force).
(I have the feeling they should be included in the "When using the location bar, suggest: xyz" preference UI)

Comment 16

[Marco Bonardo [:mak]]

Notice that someone broke idle-daily in April and we don't decay frecency nor inputhistory from then for anyone using nightlies.
I fixed it a couple weeks ago. So making assumption on current status of adaptive results is going to bring us in a black hole.

The problem here imo is not who is first, but the small space we have available in the dropdown. For a database with tens of thousands of entries, and tens of open tabs, 6(visible)-12(scrollable) results is never going to satisfy everyone.
So either we find a solution to show more content or to make the filters (only history, only bookmarks, ...) discoverable by the user. At that point if you get too many switches you can just apply filtering.

Comment 17

[Johnathan Nightingale [:johnath]]

Need UX to make a call here on desired behaviour, and also on the blocking-worthiness of any requested change.

Comment 18

[Alex Faaborg [:faaborg] (Firefox UX)]

I discussed this with Limi, and we both agree that the purpose of tab matching in the awesome bar should only be to reduce the number of duplicate tabs (as opposed to being a primary way in which users switch between tabs).  So there shouldn't be any special bonus associated with something being an existing tab other than its current frecency score and any adaptive learning that might already be associated with it.

If the user wants to specifically switch between tabs, they should:
-use the keyboard modifier to only search existing tabs (recall)
-use panorama (recognition)
-use the search interface in panorama (both recall and recognition)

We really don't want to interfere with the adaptive learning awesomeness of the awesome bar, especially since we have no indication that the user is actually trying to switch to an existing tab as opposed to going somewhere new.

Comment 19

[Alex Faaborg [:faaborg] (Firefox UX)]

I think this should block, especially considering that panorama will likely result in many users having even more tabs (which may get in the way of results when the user is attempting to navigate somewhere new).

Comment 20

[Marco Bonardo [:mak]]

Frank, if you're going to fix this, you'll have to clone and work on top of Places branch since we have a slightly different autocomplete code.
I think the fix should be pretty easy, just matter of changing the openpages query to drop pages that are in moz_places (thus it will only match pages that are not addable to history).

Comment 21

[Frank Yan (:fryn)]

(In reply to comment #20)
> Frank, if you're going to fix this, you'll have to clone and work on top of
> Places branch since we have a slightly different autocomplete code.
> I think the fix should be pretty easy, just matter of changing the openpages
> query to drop pages that are in moz_places (thus it will only match pages that
> are not addable to history).

I see. Thanks for the tip. I have other things on my plate that it may be more efficient for me to work on, so I am unassigning myself for now.

Comment 22

[Marco Bonardo [:mak]]

let's see if I can do this on the branch while we are working on it.

My plan is to make not-addable uris (those without a frecency) come first, other uris will be merged as they were before, based on their frecency.
I think there is no nice solution to merge the former type of results since they don't have a frecency, they can be at the beginning or at the end. These kind of results include things like about: pages so the issue should be limited.

Comment 23

[Marco Bonardo [:mak]]

Attachment: patch v1.0

As anticipated, this makes so that only pages not supported by history will appear first.

So ordering with this patch is:
* keywords,
* adaptive,
* open pages not supported by history (about: pages for example)
* all the rest (included open pages supported by history) ordered by frecency

without this patch it was:
* keywords,
* adaptive,
* all open pages,
* all the rest ordered by frecency

Our tests check for frecency and tab matches (for both history supported and not entries) presence in the awesomebar, I feel like those are enough.

Comment 24

[Marco Bonardo [:mak]]

Attachment: patch v1.0

sorry, this one has more context

Comment 25

[Shawn Wilsher :sdwilsh]

Comment on attachment 495015 [details] [diff] [review]
patch v1.0

r=sdwilsh

Comment 26

[Marco Bonardo [:mak]]

http://hg.mozilla.org/projects/places/rev/e88c33f1fc0b

Comment 27

[Marco Bonardo [:mak]]

http://hg.mozilla.org/mozilla-central/rev/e88c33f1fc0b