558077 - Bookmark folder and its contents lost under certain conditions of syncing same named folder

Status: VERIFIED FIXED

(Firefox :: Sync, defect)

Description

[Tracy Walker [:tracy]]

Seen with Weave1.2b4 on Fx 3.6.3 between Win XP and Mac 10.6

STR:
1) Create a new folder on the Bookmarks Toolbar on client A. Call the folder 'aaa' and give it a description 'foo'  Add 2 unique bookmarks to it. I did this by DnDing the tab favicon into the new folder.
2) Sync to server, then sync this to client B. (folder aaa with the two bookmarks should appear on the BM toolbar)
3) On client B, create another new folder on the BM toolbar.  also call it 'aaa'.  Add 2 unique bookmarks to it.
4) Sync client B to server, then sync client A.  (notice the four unique bookmarks are merged into a single folder on client A
5) Next, back on client B, add a description to the folder you created in step 3. say 'bar'
6) Delete the 2 bookmarks in that folder with description 'bar'
7) Sync client B to server, then sync client A

Tested Results:
Folder 'aaa' and its contents on client A disappear. Leaving no folders or bookmarks created for this test scenario.

Expected results:
Two folders should be present on client A  
Folder- Name: aaa, description: foo, contents: 2 original bookmarks added in step one
and
Folder- Name: aaa, description: bar, contents: none

Comment 1

[Mike Connor [:mconnor]]

Mardak, regression from bug 556509?

Comment 2

[Ed Lee :Mardak]

Nah. It's just how the dupe detection works. The descriptions are only there for the tester to be able to tell there's actually something different.

Comment 3

[Ed Lee :Mardak]

For example, if the folder names were used to differentiate them, then this bug wouldn't happen.

Comment 4

[Tracy Walker [:tracy]]

yeah, added descriptions to tell what was going on.  I guess its kind of like quantum physics, simply observing the experiment changes it's outcome.  :-)


yep, if you had a unique folder name in step 3 you wouldn't see this bug.

Comment 5

[Ed Lee :Mardak]

What's this a regression from?

Also in step 6, do you mean to only delete the 2 bookmarks or the folder with the 2 bookmarks? Because if I only delete the 2 bookmarks, only the two bookmarks get deleted on the other side.

Comment 6

[Tracy Walker [:tracy]]

I just ran this without descriptions.  Merge of contents in step 4 still happens.  but without a change (addition) of folder description in step 5, the folder on client A doesn't disappear after step 7.


in response to comment 5. only remove the contents of the folder.  You need the changed description and that folder to exist empty.

Comment 7

[Mike Connor [:mconnor]]

This is a really really contrived corner case, so it's okay to not block 1.2.  That said, all dataloss bugs are blockers for 1.3, marking accordingly.

Comment 8

[Tracy Walker [:tracy]]

sorry an additional step is required:
Step 8)  delete the folder with 'bar' as a description on client B, then sync client B, sync client A.  After that the folder disappears on client A.

Comment 9

[Ed Lee :Mardak]

Attachment: v1

We might need a version bump.. but it's a backwards compatible change, so maybe not?

Comment 10

[Mike Connor [:mconnor]]

Comment on attachment 442452 [details] [diff] [review]
v1

only thing that's potentially concerning is zany corner cases like "has duplicates pending on both sides" but I'm okay with less-aggressive merging here.

Comment 11

[Ed Lee :Mardak]

http://hg.mozilla.org/labs/weave/rev/99b662c01c44
Mark entries as dupe if they're known to be dupes locally so that receiving ends won't bother looking for dupes for these items.

Comment 12

[Tracy Walker [:tracy]]

Verified with 1.3b3

Comment 13

[Tracy Walker [:tracy]]

removing in-litmus flag, it no longer exists