Closed Bug 617521 Opened 9 years ago Closed 9 years ago

Random bookmark reordering due to dupe handling


(Firefox :: Sync, defect)

Not set



Tracking Status
blocking2.0 --- beta8+
fennec 2.0b3+ ---


(Reporter: philikon, Assigned: philikon)




(1 file)

With the old bookmark GUIDs the bookmark engine preferred "lower" GUIDs for the dupe handling and depending on whether the incoming or existing record had the "lower" GUID, it would either change the local or the remote record. It then went through great lengths to make sure all other references to that GUID were also updated. In bug 615285 I have missed some edge cases in this code that cause random reordering for those dupes.

With the random GUIDs we have now, the current behaviour is pretty much useless. When dealing with bookmark dupes we may as well just always take the upstream GUID. This means that we can we get rid of the aliasing code as well because we accept the upstream GUIDs as the arbiter of truth always.
Attached patch v1Splinter Review
Assignee: nobody → philipp
Attachment #496075 - Flags: review?(mconnor)
Comment on attachment 496075 [details] [diff] [review]

I should explain this a bit: This patch makes us always take the incoming GUID for a dupe. This simplifies the code a lot because we don't have to worry about aliases, and we're less likely to run into inconsistencies with ordering.

The patch also fixes an unrelated reference error (Log4Moz).

I created a crossweave test that tests the duping. It fails now and passes with the patch applied.
Comment on attachment 496075 [details] [diff] [review]

tests ftw!
Attachment #496075 - Flags: review?(mconnor) → review+
Closed: 9 years ago
Resolution: --- → FIXED
Blocks: 617271
blocking2.0: --- → beta8+
tracking-fennec: --- → 2.0b3+
Blocks: 621584
Component: Firefox Sync: Backend → Sync
Product: Cloud Services → Firefox
You need to log in before you can comment on or make changes to this bug.