Closed Bug 460651 Opened 16 years ago Closed 13 years ago

bookmarks load as random pages from history and change location unexpectedly

Categories

(Firefox :: Bookmarks & History, defect)

Product:
Firefox
Component:
Bookmarks & History
Version:
3.0 Branch
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED INCOMPLETE

People

(Reporter: allisoncorinne, Unassigned)

References

Details

(Keywords: common-issue-) 

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9.0.3) Gecko/2008092414 Firefox/3.0.3
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9.0.3) Gecko/2008092414 Firefox/3.0.3

since installing 3.0.3, any new bookmarks i add load as random pages from my history. old imported bookmarks load fine.

Reproducible: Always

Steps to Reproduce:
1.add bookmark 
2.click bookmark
3.bookmark loads as page from history, not the address bookmarked
Actual Results:  
bookmark loads as page from history, not the address bookmarked

Expected Results:  
it should have loaded the page i bookmarked

there are a lot of responses on the community board for this problem, but i didn't find any fixes when searching the site, or even a known issue report. i'm going to be downgrading to an earlier version, please notify me when this issue is fixed, so i can re-upgrade.
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.0.3) Gecko/2008092414 Firefox/3.0.3

I'm having the same problem as allison on Leopard, but I'll add: 
- If you try to add another bookmark it always rewrites the last one and it will never create a new one.
- The blue star stays blue for all opened tabs.
- You may encounter with a sudden deletion of some of your bookmarks. Happened to me after a restart. I reload automatically my last viewed pages.

There's a long thread on support forums (from +4 months): http://support.mozilla.com/tiki-view_forum_thread.php?locale=en-US&forumId=1&comments_parentId=66159#threadId66165

The following may be duplicates:
* Bug 447665
* Bug 458028
* Bug 462848
* Bug 457644
Summary: bookmarks load as random pages from history → bookmarks load as random pages from history and change location unexpectedly
i'm confirming for the high number of reports this got, still we don't have good STRs, or an idea if an add-on could be the cause of this.

So please, if anyone is seeing this, report the add-ons you have.
Status: UNCONFIRMED → NEW
Ever confirmed: true
also, for the same reason, if anyone is still seeing the issue, if you're not too concerned with privacy, zip up your profile and share it somewhere with a developer (you can send a private link to the download through mail)
i ended up doing a google search about a month ago and found a fix. unfortunately, i don't remember what the search parameters were or what the fix was, but it involved adding .bak files.

i'm pretty sure it was this, or something similar:

http://support.mozilla.com/en-US/kb/Firefox+3+upgrade+switches+bookmarks+and+other+settings+to+older+version
This really isn't a new bug, I've been having it (and reported it) since 3.01 I think. Really bothersome.
Chances are, if you are seeing this, you have a corrupted places.sqlite file.
Shawn:

How does one fix a corrupted places.sqlite file? :)
we don't need confirmations, we need a full zipped profile where this happens...
I'd like to add that this also happens on Intel platforms. How do I zip a profile?
You need to locate your profile folder [1], zip it up, and send it to either Marco or I.  Posting it on the bug will make the contents publicaly available, whereas we'll take a look and then destroy the file.

[1] http://support.mozilla.com/en-US/kb/Profiles#How_to_find_your_profile
Notice the profile could be quite big, you can remove from the compressed file any urlclassifier file since we don't need them.
If the file is too big to be sent by mail, you could store it on the web and share a link to download it with one of us.
Wait, profile folder like /Users/myuser ?
see the link in comment 13, that explains which profile and where.
Got it. Uploading ~23MB. I'll post the link here when it's done.
Marking comment 18 as private so it's not publicaly available to the world.
Ben, have you ever run an SQL query on the database using Sqlite Manager or another database software?
You mean the firefox database? No. I run some queries on the local machine, and some on web servers via sequel pro.
ok, thanks, i'm looking into your profile to see if i can find the culprit.
The issue is due to an internal sqlite database corruption, the corruption can be detected executing an integrity check on the database using one of these 2 sqlite commands:
pragma INTEGRITY_CHECK;
pragma QUICK_CHECK;

the fix is not straight-foward, but we are looking into this, we need to find a good place to execute an additional integrity check, and a strategy to fix the problem without bothering the user.
No longer blocks: 484634
Flags: blocking-firefox3.5?
Is this fixed or helped by bug 462366?
Hardware: PowerPC → All
no, this needs separate handling since is due to real sqlite corruption and is not recoverable.
notice that fixing this will require deep changes, since we will need to replace the database, probably providing a way to backup history (if possible), and present this to the user with a notification and probably a progress bar.

The minimum change for 3.5 could be to detect the corruption with preventive maintenance, notify the user through a notificationbar notice, telling on next restart his db will be restore and history lost, and eventually ask if user wants to restart immediately, and on next browser start replace the db and restore the backup, this will at least require a string change.
Not blocking: at this point we'd need string changes (and we're past that freeze) to make this happen, and I don't think we're seeing it commonly enough to go beyond writing a really good SUMO article about how to fix it.

Marco: will restoring from one of the backups fix the problem?

David: can we make sure there's a SUMO article on this?
Flags: blocking-firefox3.6?
Flags: blocking-firefox3.5?
Flags: blocking-firefox3.5-
Closing the browser and removing places.sqlite is the only way to fix the issue, since it's not bookmarks corruption, but real database file corruption, the backup will restore bookmarks on next start, no way to save history atm.

To disagnostic the problem user should execute "pragma INTEGRITY_CHECK;" query on places.sqlite with a third party tool (or we could provide an add-on for Shiretoko to take care of this case and maybe handle the problem in a better way).
Do we know why we're seeing corruption in the first place?
Most likely causes are crashes/power failures/borked storage devices or filesystems, but actually we rely on sqlite own capability to avoid these kind of corruptions (some old sqlite version is known to have bugs that could bring to db corruption in rare cases).
3.5 also changed sync=NORMAL to sync=FULL on places.sqlite, and that should be an additional protection against that kind of failure (and could explain some of these issues on 3.0.x).
This is the top (In reply to comment #29)
> David: can we make sure there's a SUMO article on this?

Corrupt sqlite files is the most common isolated issue reported in the support forum. We have the following articles already:

http://support.mozilla.com/en-US/kb/Bookmarks+and+toolbar+buttons+not+working+after+upgrading
http://support.mozilla.com/en-US/kb/bookmarks+not+saved
http://support.mozilla.com/en-US/kb/Cannot+log+in+to+websites (for cookies.sqlite corruption)

However, this looks like yet another symptom for sqlite corruption. We'll file a bug to get a new article created.

(In reply to comment #32)
> 3.5 also changed sync=NORMAL to sync=FULL on places.sqlite, and that should be
> an additional protection against that kind of failure (and could explain some
> of these issues on 3.0.x).

That sounds encouraging -- definitely something to monitor on SUMO to see if the number of reports is dropping.
Keywords: common-issue+
Bug 485969 for new docs per comment 33.
OS: Mac OS X → All
This seems related to bug 464486. Dupe?
is related, partly the same, but here we still need to find a strategy to fix the corruption without bothering users, replacing the db.
(In reply to comment #30)
> Closing the browser and removing places.sqlite is the only way to fix the
> issue, since it's not bookmarks corruption, but real database file corruption,
> the backup will restore bookmarks on next start, no way to save history atm.
> 
> To disagnostic the problem user should execute "pragma INTEGRITY_CHECK;" query
> on places.sqlite with a third party tool (or we could provide an add-on for
> Shiretoko to take care of this case and maybe handle the problem in a better
> way).

Hi Marco,

I followed your recommendation:

1- Close the browser
2- Go to application data - mozilla - firefox folder
3- Remove places.sqlite file

As you mentioned I lost all the history, so I think I did the right thing. At first it seemed like it was resolved but today it started replacing my bookmarks with history again. So I think your recommendation does not actually fix the issue.

Here are the add-ons that I use:

Adblock Plus 1.0.2
Dafizilla Table2Clipboard  0.2.1
Java Quick Starter 1.0
Microsoft .NET Framework assistant 1.0
Seslisozluk Lookup 1.1
SQLite Manager 0.4.8
TableTools 0.27

Thank you for your help,

-ahmet
that's quite strange, please post you user agent, and send me a compressed copy of your places.sqlite by mail.
Do you use linux by chance? if yes, which filesystem?
Nope, my OS is XP

I'll send the places.sqlite file by email now.
Ups, and that is my user agent:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.10) Gecko/2009042316 Firefox/3.0.10 (.NET CLR 3.5.30729)
your places.sqlite is not corrupt, so i cannot explain that. Is it possible that you are seeing results of the provious corruption so that bookmarks have been already replaced by other uris but you never noticed those? Or are they replaced by pages you are visiting now for the first time?
What i see in the db is that a bunch of bookmarks point to moz_places that looks like coming from history, but could be this happened before you regenerated the database.
If this is caused by corruption, what's the next step?  What's the best workaround?
rename places.sqlite to places.sqlite.bak and start browser, a new one will be generated. This will have 2 drawbacks:
- history will get lost
- if some bookmark uri has been replaced it won't be recovered (you could try restoring an older json backup on the new db)
seems to have tapered off in reports.
Keywords: common-issue+ → common-issue-
Version: unspecified → 3.0 Branch
Flags: blocking-firefox3.6? → blocking-firefox3.6-
old bug probably due to corruption/scrambling of ids in the database, doubt there is anything useful to do now.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.