Firefox unresponsive (freezes) during bookmark sync




9 years ago
5 months ago


(Reporter: aelilea, Unassigned)


Firefox Tracking Flags

(Not tracked)




9 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-GB; rv: Gecko/20100628 Ubuntu/10.04 (lucid) Firefox/3.6.6
Build Identifier: Firefox Sync 1.4 on Mozilla/5.0 (X11; U; Linux i686; en-GB; rv: Gecko/20100628 Ubuntu/10.04 (lucid) Firefox/3.6.6

Firefox becomes completely unresponsive (not even the window is redrawn) for a couple of minutes during sync.

In verbose-log.txt this would be between
2010-07-02 09:23:32 Engine.Bookmarks     INFO Records: 0 applied, 0 reconciled, 0 left to fetch
2010-07-02 09:26:37 Engine.Bookmarks     INFO Uploading all of 11 records

There do not appear to be any errors in the syncing and it completes successfully. This may therefore be "standard" behaviour which only becomes annoyingly noticeable on fairly slow machines and with large numbers of bookmarks (in my case, over 6000). However, as far as I recall, this problem was absent before Weave 1.3.

Following a suggestion from IRC chat, setting services.sync.log.logger.engine.bookmarks to Trace revealed that the unresponsive time is spent going through the bookmarks (numerous lines of the type

2010-07-02 20:43:35	Engine.Bookmarks     TRACE	Mapped: Unsorted Bookmarks,bhttp:// (...)

and similarly "Finding mapping...", "Mapped dupe...", "Outgoing..." when a change is detected. Unfortunately it appears this activity is not carried out unobtrusively in the background.

Reproducible: Always

Steps to Reproduce:
1. Ensure there is at least one change to the bookmarks
2. Sync

Actual Results:  
Firefox temporarily but completely unresponsive

Expected Results:  
Bookmarks sync carried out unobtrusively in the background

Comment 1

9 years ago
So it's probably because when it tries to detect dupes, it needs to create an in-memory mapping of your over 6000 bookmarks. Ideally we would use some built-in api to detect these dupes to avoid creating the mapping when processing incoming data.
Target Milestone: --- → 2.0

Comment 2

8 years ago
This has been one of the single most annoying behaviors of Weave/Sync since the beginning, and it still occurs to some degree as of Sync 1.5.1.  Firefox becomes completely unusable (to the point that Windows briefly states the application is not responding) during the initial part of the sync.

It has gotten somewhat better over the past year, but is still prevalent and so annoying that I would almost rather uninstall it than gain the valuable bookmark sync features it provides.
This is most likely due to the fact that Sync is using synchronous I/O on the main thread to talk to the bookmark DB. Bug 626279 is about removing that.
Depends on: 626279
Target Milestone: 2.0 → ---
We're using an increasing amount of asynchronous calls, and fixing the rest as core APIs become available.  Since we never identified a root cause for this specific instance, resolving as INCOMPLETE, but it's likely fixed or significantly better.
Last Resolved: 7 years ago
Resolution: --- → INCOMPLETE


5 months ago
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.