User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9) Gecko/2008052906 Firefox/3.0 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9) Gecko/2008052906 Firefox/3.0 When exporting bookmarks and importing them on another computer, "smart bookmark folders" / "saved search folders" are no longer working after the import Reproducible: Always Steps to Reproduce: 1: open places organizer (Ctrl+Shift+B) 2: click on tags 3: drag one of the tags to the bookmarks toolbar folder or bookmarks folder 4: result is a smart bookmark folder that when clicked shows all bookmarks with the specified tag 5: Backup bookmarks to JSON file 6: On second computer, import this JSON file Actual Results: On the second computer the restored smart bookmarks folder is empty Expected Results: On the second computer the restored smart bookmarks folder should display the same contents as on the first computer. I've tested this with a fresh profile, on both linux, vista and xp.
i can confirm this with Firefox/3.0.1 ID:2008070208 & Minefield/3.1b1pre ID:20080901033305 my STRs: - create bookmark(s) - tag this bookmark(s) - drag the created tag onto bookmarks toolbar/menu to get a "special folder" item with tag-relevant item(s) in it (only possible with Fx3 branch because of bug 453165) - export bookmarks via library to a JSON file - import this JSON file actual: "special"/tag folder has no items expected: "special"/tag folder has items unclear if those items are not being either stored or restored correctly. since it's not a regression i'm unsure if this should block 3.1, so asking.
Severity: major → minor
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: backup / restore of bookmarks results in emtpy smart bookmark folders / saved search folders → (re)storing JSON bookmark backup does not (re)store tag folder items
Version: 3.0 Branch → Trunk
Why did you change this from major to minor? It seems to fit the BMO definition of major to me.
sorry, was an accident. "normal" is okay for this issue.
Severity: minor → normal
I'm not able to create such a special folder from a source tag. So one question: Does it also happen for you with a special folder created from a search within the Library?
saved search as special folder works fine with backup/restore both on branch & trunk => so only "special folders" created by tag drag & drop seems to be affected.
It would be great if you could find the time to attach a minimal testcase of a places.sqlite with a fresh profile: 1. Bookmark a page and add a tag 2. D&D this tag to the Toolbar That would be enough for testing purposes. Thanks.
Created attachment 336393 [details] test places.sqlite attached an example places.sqlite file with one bookmark + one tag + the tag dropped to bookmark toolbar. places.sqlite was generated with Firefox/3.0.1 ID:2008070208.
I'll have a look at it tomorrow. Thanks meanwhile.
Henrik, did you have a chance to test this?
Sorry for being late here. Had to work on other things first. I've taken a look at the given test case and I can confirm that behavior. We have dataloss when restoring from a JSON backup. The contents of folders which are copies from a special query are not restored. Raising severity of this bug and adding dataloss keyword. Marco, something you could have a look at?
Severity: normal → critical
Keywords: dataloss, testcase
Flags: blocking-firefox3.1? → blocking-firefox3.1+
Priority: -- → P1
Target Milestone: --- → Firefox 3.1
Hrm, I misunderstood the when reviewing this for blocking earlier. This is a saved search, so there's not dataloss other than the saved search being broken after a restore. The items themselves are pointers to other items... which are not deleted. The workaround for the moment is to recreate the saved search. The way to fix this is to fix bug 399799, providing full tag support in the Places query infrastructure. Marking blocking- since it's a known limitation in 3.0 that saved searches for tag containers don't persist, and because there's not really dataloss.
Severity: critical → normal
Flags: blocking-firefox3.1+ → blocking-firefox3.1-
Priority: P1 → P2
Summary: (re)storing JSON bookmark backup does not (re)store tag folder items → restoring JSON bookmark backup does not restore saved searches of tag containers
Dietrich, sorry but as you have already said, items like saved searches for tag containers are not restored. Even when we don't lose any bookmark on restore the user will lose his created saved searches. Please imagine that it could be only 10 or even hundreds of this saved searches ordered somewhere on the toolbar in different folders. All of them will be lost after a restore and have to be re-created manually. That's why I cannot see why we don't have dataloss here.
Severity: normal → critical
There is nothing preventing a user from re-creating those searches. I agree this is painful, but there is no data that is permanently lost, unable to be restored. Bug 399799 is on my mind constantly, as so many cool features (as well as fixing this bug) would be possible with it resolved. However, neither those features nor this bug are severe enough to block the whole 3.1 release.
Severity: critical → major
Target Milestone: Firefox 3.1 → Firefox 3.2a1
Due to this bug it's basically impossible for a user who makes heavy use of smart folders to use the Firefox's native import/export function, Weave or Foxmarks to sync bookmarks between several computers. Every time a sync happens the users smart folders stop working and have to be recreated. When using the import/export function occasionally this isn't a huge deal, even for someone who has lots of smart folders. But it makes synchronizing between 2 Firefox installations prohibitively cumbersome. The Weave related bug is here: Bug 479189 The Foxmarks related bug is here: http://getsatisfaction.com/foxmarks/topics/custom_smart_bookmarks_are_disappearing
asking for wanted‑firefox3.6 since bug 399799 is now fixed.
Bug 451915 - move Firefox/Places bugs to Firefox/Bookmarks and History. Remove all bugspam from this move by filtering for the string "places-to-b-and-h". In Thunderbird 3.0b, you do that as follows: Tools | Message Filters Make sure the correct account is selected. Click "New" Conditions: Body contains places-to-b-and-h Change the action to "Delete Message". Select "Manually Run" from the dropdown at the top. Click OK. Select the filter in the list, make sure "Inbox" is selected at the bottom, and click "Run Now". This should delete all the bugspam. You can then delete the filter. Gerv
Component: Places → Bookmarks & History
QA Contact: places → bookmarks
This has been fixed by bug 1293445 in FF 61.
Status: NEW → RESOLVED
Last Resolved: a month ago
Resolution: --- → FIXED
status-firefox60: --- → wontfix
status-firefox-esr52: --- → wontfix
status-firefox-esr60: --- → wontfix
You need to log in before you can comment on or make changes to this bug.