The default bug view has changed. See this FAQ.

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

RESOLVED FIXED in Firefox 10

Status

()

Firefox
Bookmarks & History
RESOLVED FIXED
6 years ago
6 years ago

People

(Reporter: Stefan, Unassigned)

Tracking

Trunk
Firefox 10
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

6 years ago
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.
(Reporter)

Comment 1

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

Updated

6 years ago
Component: General → Bookmarks & History
OS: Other → All
QA Contact: general → bookmarks
Hardware: Other → All
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.
(Reporter)

Comment 3

6 years ago
(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
(Reporter)

Comment 4

6 years ago
referential integrity?
(Reporter)

Comment 5

6 years ago
"Orphans expiration" eventually removed the entry from the DB.
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.
(Reporter)

Comment 7

6 years ago
(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.
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.
(Reporter)

Comment 9

6 years ago
(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?
(Reporter)

Comment 10

6 years ago
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.
(Reporter)

Comment 11

6 years ago
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.
(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.
(Reporter)

Comment 13

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

Updated

6 years ago
Depends on: 692493

Updated

6 years ago
Status: UNCONFIRMED → NEW
Ever confirmed: true
Bug 692493 added checks on this coherence to weekly maintenance, so this should disappear from the wild.
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 10
You need to log in before you can comment on or make changes to this bug.