Closed
Bug 641207
Opened 15 years ago
Closed 14 years ago
Bookmarks display in sidebar empty, but bookmarks show when clicking bookmarks button
Categories
(Firefox :: Bookmarks & History, defect)
Tracking
()
RESOLVED
INCOMPLETE
People
(Reporter: dennis.mccunney, Unassigned)
Details
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:2.0) Gecko/20100101 Firefox/4.0
Build Identifier: Mozilla/5.0 (Windows NT 5.1; rv:2.0) Gecko/20100101 Firefox/4.0
(Hopefully this is not a duplicate of an existing bug. A search didn't reveal obvious candidates.)
I normally use the Sidebar to display the bookmarks list. This broke upgrading from FF 4.0 Beta13Pre nightly to FF 4.0 RC1. Instead of my expected bookmarks display, I see three entries with (no title) as the description. I *do* see my expected bookmarks list when clicking the bookmarks button on the toolbar.
Reproducible: Always
Steps to Reproduce:
1. Install FF 4.0 RC1
2. Open FF 4.0 RC1 using existing profile
3. Open Sidebar to view bookmarks
Actual Results:
Bookmarks list contains 3 entries with (no title) as the description
Expected Results:
A normal display of my bookmarks in the Sidebar panel
This behavior persisted even after an FF 4.0 restart with extensions disabled, so it's not an add-on conflict.
To make matters thoroughly confusing, clicking on the Bookmarks button in the toolbar *shows* my expected bookmarks list.
Looking in the profile directory, I see that my former places.sqlite is gone, replaced by places.sqlite.CORRUPT, and a default places.sqlite file has been created.
So my questions are:
1) Why is FF deciding my places.sqlite file is corrupt and replacing it with an empty default copy? I saw this behavior when trying to use a places.sqlite file from my 3.6 installation in 4.0 beta, gave up, and imported a backup, assuming some incompatibility between 3.6 and 4.0 bookmark handling. It was an unpleasant surprise to see it happen going from FF 4 Beta to FF 4 RC1.
2) Since it *shows* my expected bookmarks file when clicking on the Bookmarks button, where is it *getting* that list? It's certainly not getting it from the places.sqlite file.
Any guidance that will help me understand what is happening will be welcomed. So will any suggestions about further info I can provide to track down what is occurring.
______
Dennis
Comment 1•15 years ago
|
||
Did you use Weave/Firefox Sync at all or any other Bookmark/History related Extensions?
Component: General → Bookmarks & History
QA Contact: general → bookmarks
Version: unspecified → Trunk
| Reporter | ||
Comment 2•15 years ago
|
||
(In reply to comment #1)
> Did you use Weave/Firefox Sync at all or any other Bookmark/History related
> Extensions?
I did not and do not plan to use Weave/Sync.
The only extension I use vaguely related to Bookmarks is All-In-One-Sidebar, which doesn't affect the bookmarks - only the way they might display in the Sidebar.
As mentioned, the behavior persisted when I restarted FF 4.0 RC1 will add-ons disabled to rule out possible conflicts.
I'm assuming FF 4.0 RC1 is *very* similar to current 4.0 Beta13Pre nightlies in terms of underlying code, so I'm at a loss to understand where this problem comes from.
I'm currently running with an older profile that's substantially the same as the one I was using, and a mostly up to date bookmarks file.
But I'm still *very* confused about bookmarks handling. Under FF 3.6, my places.sqlite file was about 34MB. In FF 4.0 RC1, it's the default 10MB size, yet I'm seeing what appears to be the full set.
Where is it getting the bookmarks? Have dramatic changes been made to the underlying SQLite database that have the effect of reducing the size of the places.sqlite file?
And where was it getting the bookmarks before, when they showed correctly while clicking on the Bookmarks toolbar, but were absent in the sidebar panel?
Thanks in advance for any helpful information.
______
Dennis
Comment 3•15 years ago
|
||
(In reply to comment #0)
> This behavior persisted even after an FF 4.0 restart with extensions disabled,
> so it's not an add-on conflict.
This could be untrue, from what you said your places.sqlite has been considered corrupt, and replaced with a new one, at this point some task ran to create your sidebar entries, and an add-on could have absolutely ruined this.
> Looking in the profile directory, I see that my former places.sqlite is gone,
> replaced by places.sqlite.CORRUPT, and a default places.sqlite file has been
> created.
Could you open that .corrupt file with an external sqlite explorer/manager and run on it this query: PRAGMA integrity_check; What does it return?
> 1) Why is FF deciding my places.sqlite file is corrupt and replacing it with an
> empty default copy?
Because it could be corrupt
> 2) Since it *shows* my expected bookmarks file when clicking on the Bookmarks
> button, where is it *getting* that list? It's certainly not getting it from
> the places.sqlite file.
the problem are not bookmarks, but something broke the creation of the folders we use in the sidebar.
(In reply to comment #2)
> The only extension I use vaguely related to Bookmarks is All-In-One-Sidebar,
> which doesn't affect the bookmarks - only the way they might display in the
> Sidebar.
I'd not put my hand on fire about this.
> But I'm still *very* confused about bookmarks handling. Under FF 3.6, my
> places.sqlite file was about 34MB. In FF 4.0 RC1, it's the default 10MB size,
> yet I'm seeing what appears to be the full set.
since your file was considered corrupt, it was recreated and this right now loses history data, plus making a new db solves fragmentation problems.
Could you try to open the Library from Firefox > Bookmarks and then retry opening the sidebar?
Comment 4•14 years ago
|
||
Dennis -> Any update?
Comment 5•14 years ago
|
||
Closing bug as Incomplete - if you are still experiencing this issue or have more information to provide feel free to post back here and we can re-open the bug. You can also get assistance by visiting the Firefox help site -> https://support.mozilla.com/en-US/kb/ask
Status: UNCONFIRMED → RESOLVED
Closed: 14 years ago
Resolution: --- → INCOMPLETE
You need to log in
before you can comment on or make changes to this bug.
Description
•