Bookmark reconciling uses parent name when parent ID would yield better results

RESOLVED DUPLICATE of bug 1305563

Status

()

Firefox
Sync
P3
normal
RESOLVED DUPLICATE of bug 1305563
6 years ago
a month ago

People

(Reporter: rnewman, Unassigned)

Tracking

(Blocks: 1 bug)

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [data-integrity])

(Reporter)

Description

6 years ago
I noticed that bookmarks I created in Fennec were being duplicated on desktop.

Here's the reason.

If we map an item by GUID, all is well. Of course, this doesn't always occur.

If that doesn't happen, we search in guidMap. We do this by searching under the parent name (which can collide, of course!) and then by a concatenated search string.

If a record arrives like this (forgive abbreviated JSON):

  {id: "abcdefghijkl",
   parentId: "mobile",
   parentName: "Mobile Bookmarks",
   bmkUri: "http://slashdot.org/",
   title: "Slashdot"}

and locally we have

  {id: "gggggggggggg",
   parentId: "mobile",
   parentName: "mobile",
   bmkUri: "http://slashdot.org/",
   title: "Slashdot"}

-- because Places doesn't store a real name for Mobile Bookmarks -- then our guidMap search *will yield nothing* because there is no folder named "Mobile Bookmarks".

We'll deduce that this is a new record, and yet we'll store it in the folder with ID "mobile".

Now you have two Slashdot bookmarks in the same folder, despite not being able to find one during reconciling!

Bug.
(Reporter)

Comment 1

6 years ago
I believe this *only* applies to the "mobile" folder.
(Reporter)

Comment 2

6 years ago
Fixed on Android (Bug 748898) by translating the names of special folders inbound, to the local expected value, and outbound, to the same (which happens to be what desktop expects).

Desktop could do something similar here.
(Reporter)

Updated

5 years ago
Blocks: 821586
Whiteboard: [sync:bookmarks]
CC mak as this bug is relevant to the discussion in bug 1012597.
(In reply to Richard Newman [:rnewman] from comment #0)
> If a record arrives like this (forgive abbreviated JSON):
> 
>   {id: "abcdefghijkl",
>    parentId: "mobile",
>    parentName: "Mobile Bookmarks",
>    bmkUri: "http://slashdot.org/",
>    title: "Slashdot"}
> 
> and locally we have
> 
>   {id: "gggggggggggg",
>    parentId: "mobile",
>    parentName: "mobile",
>    bmkUri: "http://slashdot.org/",
>    title: "Slashdot"}
> 
> -- because Places doesn't store a real name for Mobile Bookmarks -- then our
> guidMap search *will yield nothing* because there is no folder named "Mobile
> Bookmarks".

I don't quite understand this - how did the name get different? Because they were created on different devices, or due to the user renaming? I guess the former, but if the latter, then this sounds like bug 1276969.

> I believe this *only* applies to the "mobile" folder.

Is this just because Fennec doesn't touch the tree structure for any other folders, or some other reason? ie, it's not immediately obvious why this isn't a problem for the other top-level folders we care about.
Flags: needinfo?(rnewman)
(Reporter)

Comment 5

a year ago
I've never renamed. I don't know why desktop just uses "mobile":

sqlite> select guid, title from moz_bookmarks where id = 474;
guid          title
------------  ----------
UjAHxFOGEqU8  mobile

Mobile platforms upload records with descriptive names ("Mobile Bookmarks").

New desktop profiles might create Mobile Bookmarks with a better name -- I see `mobile.label` = "Mobile Bookmarks" in fx-team.


Presumably this would also happen when syncing devices in different locales; my Armenian device sure isn't going to have "Bookmarks Toolbar", but it'll have the same GUID as my English device! So I was wrong: this probably affects _any_ default folder in that case.


Checking for GUID before we check for parent name might be tricky with guidMap as it stands, but it does get us closer to how iOS does content-based reconciling: top-down, same parent folder only, not parent folder of the same name!
Flags: needinfo?(rnewman)
Whiteboard: [sync:bookmarks] → [sync:bookmarks][fxsync]
Changing the component in an effort to make this show up on the sync triage list.
Component: Firefox Sync: Backend → Sync
Product: Cloud Services → Firefox
Whiteboard: [sync:bookmarks][fxsync] → [sync:bookmarks]
Whiteboard: [sync:bookmarks]
Priority: -- → P3
Whiteboard: [data-integrity]
(Reporter)

Updated

11 months ago
See Also: → bug 1323333
Added a test to bug 1305563.
Status: NEW → RESOLVED
Last Resolved: a month ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1305563
You need to log in before you can comment on or make changes to this bug.