Closed
Bug 1472943
Opened 6 years ago
Closed 6 years ago
Firefox not using latest synchronization information
Categories
(Firefox :: Sync, defect)
Tracking
()
RESOLVED
DUPLICATE
of bug 1353641
People
(Reporter: richard.focke, Unassigned)
Details
Attachments
(6 files)
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:61.0) Gecko/20100101 Firefox/61.0
Build ID: 20180621125625
Steps to reproduce:
1. Setup two PCs with Firefox synchronization (PC 1 and PC 2)
2. Create a custom toolbar and/or organize your folders on one PC 1 with firefox closed on the other.
3. Optionally close firefox on the first PC 1.
4. Open firefox on the second PC 2, and the folders order will be reverted.
Actual results:
Folder sorting and order is not maintained from the latest synchronization information. Instead a stale version from an unopened browser takes precedence.
Expected results:
Folder sorting should be maintained as per the latest synchronization information.
Comment 1•6 years ago
|
||
I've reproduced the issue on Fx61.0.1 20180704003137, Fx63.0a1 20180706100210, Fx 60.1.0esr
20180621121604, Fx52.9.0 20180621064021 on Ubuntu 16.04/ Windows 10.
Status: UNCONFIRMED → NEW
status-firefox61:
--- → affected
status-firefox62:
--- → affected
status-firefox63:
--- → affected
status-firefox-esr52:
--- → affected
status-firefox-esr60:
--- → affected
Component: Untriaged → Firefox Sync: Backend
Ever confirmed: true
Product: Firefox → Cloud Services
Comment 2•6 years ago
|
||
This sounds a lot like bug 1474033, but that only affects 62+, and I see the original report says 61. Richard, are you using Beta 62 or Nightly 63 on any of your PCs?
Flags: needinfo?(richard.focke)
Reporter | ||
Comment 3•6 years ago
|
||
Hi Lina, I am using 61 at the moment, and ESR on my work machine Windows VM. I have tested with and without the ESR and it does not appear to be the cause. I still don't have the beta version 62 installed. However, I do have the Nightly 63 on one machine, but I did not use it for the testing. Would you like me to test with that too?
Flags: needinfo?(richard.focke)
Comment 4•6 years ago
|
||
Thanks, Richard!
I can't reproduce with two Firefox 61 installs (or two 61s and an ESR 52) yet...once I sign in to a device running 62 or 63, the moves start getting reverted, but not with just 52/61. I'll keep poking at it, though.
In the meantime, if you have cycles to help us debug, could you please install the About Sync add-on (https://addons.mozilla.org/en-US/firefox/addon/about-sync/), open about:sync, set "Actively looking for issues and want detailed logging" under the "General Options" section, and test again?
When you notice the moves are reverted, please download the logs as a zip file (there's a link under "Log Files and Diagnostics" in about:sync), and attach them to this bug, along with an anonymized "validation export" ("Data provider options" section at the bottom). That'll give us a better idea of what your devices are doing.
Also, could you please check if you have the `services.sync.engine.bookmarks.buffer` pref enabled or disabled in about:config?
Flags: needinfo?(richard.focke)
Reporter | ||
Comment 5•6 years ago
|
||
I am busy installing the about-sync addon. I will test a bit further tonight. Unfortunately, my day schedule is very busy so I probably won't be able to test before then. The flag `services.sync.engine.bookmarks.buffer` is false in my about:config on the two Firefox 61.0.1 instances. This seems to be a new setting my Firefox ESR 52.9.0 (32-bit) does not have it - I am using this predominantly to access some pages serving Java applets.
Flags: needinfo?(richard.focke)
Reporter | ||
Comment 6•6 years ago
|
||
Synchronization was done around 07:05
Reporter | ||
Comment 7•6 years ago
|
||
Synchronization completed at 07:05 but no new log file present.
Reporter | ||
Comment 8•6 years ago
|
||
Ok, I quickly tested with the plugin. What I see is that on the machine, where I re-order the bookmarks the synchronization, is the bookmark order is uploaded to the server. On the other machine, where the synchronization was meant to be pushed, it synchronizes but makes no new log file. Despite having successfully synchronized. I assumed with the plugin option that a log file would always be created? I have attached all the log files created, but have not removed any older logs.
Reporter | ||
Comment 9•6 years ago
|
||
Synchronization finally kicks in fully and order is now jumbled (neither order maintained).
Reporter | ||
Comment 10•6 years ago
|
||
Relaunched firefox and bookmarks are jumbled even on main machine.
Reporter | ||
Comment 11•6 years ago
|
||
Launching Firefox again on the master machine (where the changes were first made) now leads to both machines having random ordering of bookmarks.
Comment 12•6 years ago
|
||
As you say, the logs show that around 15:05, some items were moved on the toolbar, and this machine synced. However, the last log from machine 2 is dated 14:57:42. That is a "success" log, so we'd certainly expect future syncs to also write "success" logs. So I've no idea why machine 2 does seem to be syncing, but didn't sync when you expected it to. However, in general, machine 2 does seem to be syncing correctly.
about:sync has a "validation" tab - it would be interesting to know what each of the machines reports there.
Now that you have about:sync installed on both those machines, any logs you send in the future will become a bit clearer, so I look forward to them once you've found time to have another play with this.
(In reply to Richard Focke from comment #11)
> Launching Firefox again on the master machine (where the changes were first
> made) now leads to both machines having random ordering of bookmarks.
Ouch! Could you please attach any new logs from that machine after success-sync-1531285523774.txt?
Comment 13•6 years ago
|
||
I also meant to ask: your account appears to have 6 devices connected to the account. Are any of the other 4 Android devices?
Reporter | ||
Comment 14•6 years ago
|
||
Hi Mark, yes two of the devices are Android devices. Would this make a difference? I wasn't using Firefox on the Android at the time but it was connected to the Internet.
Reporter | ||
Comment 15•6 years ago
|
||
Unfortunately, I will only be able to test again tonight.
Comment 16•6 years ago
|
||
Sadly we do have a number of Android bugs related to ordering :( It would be very helpful if you can do your testing with these devices disconnected (eg, in Airplane mode) and ensuring that the bad ordering only happens when they are connected.
(In reply to Richard Focke from comment #15)
> Unfortunately, I will only be able to test again tonight.
No problem at all - we are quite busy here too, so it may end up taking us a couple of days to get back to you anyway - so please don't rush on our account!
Reporter | ||
Comment 17•6 years ago
|
||
Seems it is the Android devices causing havoc. With them in flight mode the issue stops happening.
Reporter | ||
Comment 18•6 years ago
|
||
Re-ordering on first machine with Android(s) in flight mode.
Reporter | ||
Comment 19•6 years ago
|
||
Reporter | ||
Comment 20•6 years ago
|
||
I performed the test around 9:00
Comment 21•6 years ago
|
||
Thanks! We are tracking the Android reordering issue via bug 1353641
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → DUPLICATE
Assignee | ||
Updated•6 years ago
|
Component: Firefox Sync: Backend → Sync
Product: Cloud Services → Firefox
Updated•5 years ago
|
You need to log in
before you can comment on or make changes to this bug.
Description
•