All users were logged out of Bugzilla on October 13th, 2018
The "Mobile" folder in the Places DB in XUL Fennec is a root folder for bookmarks, but it is not listed in moz_bookmarks_roots. Reading through the comments surrounding code using that table, I see no reason for it not to be there. See also Bug 752444, and this probably also causes Bug 747699. If this was by design it would be good to explain the reasoning.
Basically the Mobile root is an hack that was added when Mobile decided to sync to a separate folder, Places doesn't have the concept of "adding a root", it always only considers the predefined ones; the roots concept itself is broken by design (moz_bookmarks_roots is a quite useless table too), I would really like if it wouldn't ever existed at all, we are keeping it just for retro-compatibility.
Alright. What's the preferred way of identifying a certain folder? i.e. if I want to get the Bookmarks Menu", "Bookmarks Toolbar", "Unsorted bookmarks" folder, how should that be done? Are the id's guaranteed to be fixed? (From comments in the sync code, the GUID's aren't.)
(In reply to Gian-Carlo Pascutto (:gcp) from comment #2) > Alright. What's the preferred way of identifying a certain folder? i.e. if I > want to get the Bookmarks Menu", "Bookmarks Toolbar", "Unsorted bookmarks" > folder, how should that be done? Are the id's guaranteed to be fixed? (From > comments in the sync code, the GUID's aren't.) The mobile root is annotated "mobile/bookmarksRoot". The other roots are found in the roots table.
Ok, so this should work: SELECT item_id FROM moz_items_annos AS annos JOIN moz_anno_attributes AS attrib ON annos.anno_attribute_id=attrib.id WHERE attrib.name="mobile/bookmarksRoot" Bug 752444 already went in using the observation that the root ids have a fixed numbering in practice due to how the database is created. The above would allow a slightly cleaner (ahem) fix.
Wontfixing based on above comments. Profile Migration in Fennec XUL currently uses the following: "SELECT id FROM moz_bookmarks " + "WHERE id=6 AND type=2 AND fk IS NULL AND parent=1"; instead of what it should have been in my previous comment. From what I understand, this should actually work correctly, and it's what we had in the beta. So I'll keep it unless someone points out it's flawed anyway.
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → WONTFIX
fine, I think Places will also stop relying on that useless _roots table.
You need to log in before you can comment on or make changes to this bug.