1293163 - Bookmark folder de-duping changes item GUID without changing references in child records

Status: RESOLVED DUPLICATE of bug 1305563

(Firefox :: Sync, defect, P3)

Description

[Mark Hammond [:markh] [:mhammond]]

This is "the other direction" of bug 1276823. If a folder is de-duped (and thus has its GUID changed), all children in the folder still refer to the old GUID as the parentid.

This will be subtle to get right - see bug 1276823 comment 5 and bug 1276823 comment 11 in particular.

Comment 1

[Mark Hammond [:markh] [:mhammond]]

Kit, I think bug 1366888 is likely to fix this as a side-effect, right?

Comment 2

[Lina Butler [:lina]]

Yes, thanks for reminding me of this! It'll help, and I think we still need to consider bumping the change counter for NORMAL items moved into a NEW folder that's then deduped. Keeping the same non-structural merge strategy means this is going to be tricky. :-) I need to think some more and write tests for how we expect this to work.

Comment 3

[Lina Butler [:lina]]

I think our new merge strategy obsoletes this in two ways. First, we no longer use the `parentid` to determine a child's parent, and instead rely on the parent's `children` array. (We'll still need to make sure the `parentid` is correct for older Desktops and Fennec, though).

Second, we only consider bookmarks that haven't been uploaded yet for duping. We don't need to reupload records for the folder and children, or upload tombstones for the old GUIDs, because they don't exist on the server yet. If they're already on the server, they won't be candidates for deduping. IOW, we'll only ever dupe local to remote.