Last Comment Bug 685977 - Urlbar's first hit neither from History nor from Bookmarks?
: Urlbar's first hit neither from History nor from Bookmarks?
Status: RESOLVED FIXED
:
Product: Firefox
Classification: Client Software
Component: Bookmarks & History (show other bugs)
: Trunk
: All All
: -- normal (vote)
: Firefox 10
Assigned To: Nobody; OK to take it and work on it
:
:
Mentors:
Depends on: 692493
Blocks:
  Show dependency treegraph
 
Reported: 2011-09-09 12:20 PDT by Stefan
Modified: 2011-10-10 12:16 PDT (History)
3 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments

Description Stefan 2011-09-09 12:20:41 PDT
User Agent:  

Steps to reproduce:

1. Ensure you have no URL with books.google in history and bookmarks.
2. browser.urlbar.default.behavior = 1 (urlbar from History)
3. Enter "goo" in location bar.


Actual results:

3. First in list is "books.google.com"


Expected results:

Do not show URL from bookmarks.
Comment 1 Stefan 2011-09-09 12:57:34 PDT
I can't delete the URL from urlbar (shift-delete?) permanently.
Comment 2 Marco Bonardo [::mak] 2011-09-19 12:52:47 PDT
How did you check point 1?
comment 1 seems to indicate it's a bogus entry, or it may be a tag added to a not bookmarked entry by an add-on. would be interesting to do a search for "books.google.com" directly in SQLite Manager to check where it is.
Comment 3 Stefan 2011-09-19 13:52:19 PDT
(In reply to Marco Bonardo [:mak] from comment #2)
> How did you check point 1?

I inspected history and bookmarks.

> comment 1 seems to indicate it's a bogus entry, or it may be a tag added to
> a not bookmarked entry by an add-on. would be interesting to do a search for
> "books.google.com" directly in SQLite Manager to check where it is.

sqlite> select * from moz_places where url like '%books.google.%';
5555|http://books.google.com/|Google Books|moc.elgoog.skoob.|15|0|1|9431|0||XZeG4tITBbQi
Comment 4 Stefan 2011-09-19 14:05:48 PDT
referential integrity?
Comment 5 Stefan 2011-09-19 14:12:29 PDT
"Orphans expiration" eventually removed the entry from the DB.
Comment 6 Marco Bonardo [::mak] 2011-09-19 15:44:21 PDT
may be some referential integrity issue, yes, looking at comment 3, it has a completely broken visit_count. We rely on visit_count for various tasks, so my question is whether you changed that value manually or manually removed visits from the db, or have any add-on that may have done that.
Comment 7 Stefan 2011-09-20 04:10:23 PDT
(In reply to Marco Bonardo [:mak] from comment #6)
> my question is whether you changed that value manually or manually removed
> visits from the db, or have any add-on that may have done that.

Not that I know of.

> looking at comment 3, it has a completely broken visit_count.

Is moz_places.id's visit_count expected to be equal to number of records in moz_historyvisits where places_id = moz_places.id? That profile has lots of visit_count values which are either less than or greater than the number of the corresponding records in moz_historyvisits.
Comment 8 Marco Bonardo [::mak] 2011-09-20 06:08:41 PDT
there's a bug around to enable visit_count fixup in Places maintenance, that should fix those, when implemented. Usually it's hard that visit_count goes out of sync, but I know for sure some add-on and some user like to touch the database. Also really old profiles may contain wrong data in rare situations.
Comment 9 Stefan 2011-09-20 06:36:13 PDT
(In reply to Marco Bonardo [:mak] from comment #8)
> there's a bug around to enable visit_count fixup in Places maintenance

Do you have a pointer?
Comment 10 Stefan 2011-09-20 07:58:46 PDT
I have recalculated all the visit_counts and the problem is gone. That profile IS really old and has been used for testing purposes with many different Fx versions out of sequence. As far as I'm concerned the bug can be closed.
Comment 11 Stefan 2011-09-20 15:52:11 PDT
Marco, I have used the profile with the recalculated visit_counts some time and when I look into the database I find the invariant (comment #7) violated again. So I would like to ask you whether the invariant stated in comment #7 is correct.
Comment 12 Marco Bonardo [::mak] 2011-09-21 00:12:45 PDT
(In reply to Stefan from comment #11)
> Marco, I have used the profile with the recalculated visit_counts some time
> and when I look into the database I find the invariant (comment #7) violated
> again. So I would like to ask you whether the invariant stated in comment #7
> is correct.

visit_count is not exactly the same number of entries, must be <= of the number of entries. This is because some visits have poor value. Excluded types are (0, 4, 7, 8), where 0 and 4 are unlikely to exist in current version, 7 is downloads, 8 is user initiated visits in frames.
Comment 13 Stefan 2011-09-21 03:15:59 PDT
OK. I will recalculate with visit_type in (1, 2, 3, 5, 6).
Comment 14 Marco Bonardo [::mak] 2011-10-10 12:16:53 PDT
Bug 692493 added checks on this coherence to weekly maintenance, so this should disappear from the wild.

Note You need to log in before you can comment on or make changes to this bug.