685977 - Urlbar's first hit neither from History nor from Bookmarks?

Status: RESOLVED FIXED

(Firefox :: Bookmarks & History, defect)

Description

[Stefan]

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]

I can't delete the URL from urlbar (shift-delete?) permanently.

Comment 2

[Marco Bonardo [:mak]]

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]

(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]

referential integrity?

Comment 5

[Stefan]

"Orphans expiration" eventually removed the entry from the DB.

Comment 6

[Marco Bonardo [:mak]]

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]

(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]]

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]

(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]

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]

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]]

(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]

OK. I will recalculate with visit_type in (1, 2, 3, 5, 6).

Comment 14

[Marco Bonardo [:mak]]

Bug 692493 added checks on this coherence to weekly maintenance, so this should disappear from the wild.