444601 - restoring JSON bookmark backup does not restore saved searches of tag containers

Status: RESOLVED FIXED

(Firefox :: Bookmarks & History, defect, P3)

Description

[Axel Taferner]

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.

Comment 1

[(mostly gone) XtC4UaLL [:xtc4uall]]

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.

Comment 2

[Paul J. Weiss]

Why did you change this from major to minor? It seems to fit the BMO definition of major to me.

Comment 3

[(mostly gone) XtC4UaLL [:xtc4uall]]

sorry, was an accident. "normal" is okay for this issue.

Comment 4

[Henrik Skupin [:whimboo][⌚️UTC+2]]

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?

Comment 5

[(mostly gone) XtC4UaLL [:xtc4uall]]

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.

Comment 6

[Henrik Skupin [:whimboo][⌚️UTC+2]]

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.

Comment 7

[(mostly gone) XtC4UaLL [:xtc4uall]]

Attachment: 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.

Comment 8

[Henrik Skupin [:whimboo][⌚️UTC+2]]

I'll have a look at it tomorrow. Thanks meanwhile.

Comment 9

[(mostly gone) XtC4UaLL [:xtc4uall]]

Henrik, did you have a chance to test this?

Comment 10

[Henrik Skupin [:whimboo][⌚️UTC+2]]

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?

Comment 11

[Dietrich Ayala (:dietrich)]

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.

Comment 12

[Henrik Skupin [:whimboo][⌚️UTC+2]]

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.

Comment 13

[Dietrich Ayala (:dietrich)]

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.

Comment 14

[Axel Taferner]

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

Comment 15

[(mostly gone) XtC4UaLL [:xtc4uall]]

asking for wanted‑firefox3.6 since bug 399799 is now fixed.

Comment 16

[Gervase Markham [:gerv]]

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

Comment 17

[Mark Banner (:standard8)]

This has been fixed by bug 1293445 in FF 61.