755669 - bookmark operations blocked with sync

Status: RESOLVED WORKSFORME

(Firefox :: Bookmarks & History, defect)

Description

[Thomas Wolff]

User Agent: Mozilla/5.0 (Windows NT 5.1; rv:12.0) Gecko/20120429 Firefox/12.0 SeaMonkey/2.9.1
Build ID: 20120429011004

Steps to reproduce:

Manage bookmarks, e.g. move one around or into a folder.
Firefox Sync was active.


Actual results:

Bookmarks management was blocked for 20 seconds.


Expected results:

Normal operation unblocked, not delayed or frozen.

Duplicate check:
I see Bug #718309 - Bookmark freezes - Bookmark library unmanageable any more -
but it discusses local issues, analyses sqlite etc which isn't related to sync so it's likely not a duplicate.
I see Bug #711372 - Bookmark Library Hangs after a few operations -
but it doesn't mention sync at all. Symptoms are similar, though, but there've been delay problems with bookmarks since Firefox 3 without sync anyway :( - probably not a duplicate either.
I see Bug #710080 - firefox sync freeze firefox while syncing -
this one could be a duplicate, however, it says Firefox would be blocked while in fact I observe only the Bookmarks Manager ("Library" window) to be blocked.

Comment 1

[Thomas Wolff]

"Importance": I consider this critical because being unbearable it effectively blocks bookmarks management and thus makes the sync feature completely useless.

"Product": same in SeaMonkey (but I don't see a common component to target the bug to).

Comment 2

[Marco Bonardo [:mak]]

May you please install about:telemetry add-on and next time it happens post the SQL queries from the top part of that page?
Do you have any other add-ons that may interact with bookmarks?

Comment 3

[Thomas Wolff]

You mean the app.telemetry add-on? It shows some bar diagrams in the about:telemetry tab but no SQL anywhere...
Meanwhile I can confirm that with Firefox 13 the problem persists - in contrast to what is claimed in another bug.
I have 10 seconds of bookmarks unusability after moving a group of bookmarks into a folder.

Comment 4

[Thomas Wolff]

Managed to get the requested diagnostics now.
about:telemetry (which is also the only add-on installed right now) shows this:

Slow SQL Statements on Other Thread Hits	Avg. Time (ms)	Statement
1	103	SELECT h.url, h.title, f.url, EXISTS(SELECT 1 FROM moz_bookmarks WHERE fk = h.id) AS bookmarked, ( SELECT title FROM moz_bookmarks WHERE fk = h.id AND title NOTNULL ORDER BY lastModified DESC LIMIT 1 ) AS btitle, ( SELECT GROUP_CONCAT(t.title, ',') FROM moz_bookmarks b JOIN moz_bookmarks t ON t.id = +b.parent AND t.parent = :parent WHERE b.fk = h.id ) AS tags, h.visit_count, h.typed, h.id, :query_type, t.open_count FROM moz_places h LEFT JOIN moz_favicons f ON f.id = h.favicon_id LEFT JOIN moz_openpages_temp t ON t.url = h.url WHERE h.frecency <> 0 AND AUTOCOMPLETE_MATCH(:searchString, h.url, IFNULL(btitle, h.title), tags, h.visit_count, h.typed, bookmarked, t.open_count, :matchBehavior, :searchBehavior) ORDER BY h.frecency DESC, h.id DESC LIMIT :maxResults

Comment 5

[Thomas Wolff]

Not having any Mozilla insider knowledge that would tell me anything about how this SQL should work, I notice though that it contains the operation "JOIN" three times.
For a simple reattachment of some data records in a simple DB structure, i.e.!
Sounds like a really huge design problem.

Comment 6

[Marco Bonardo [:mak]]

The query above is a search in the locationbar, not causing a lock (it took 103ms fwiw), so not related. Looks like your issue is not due to a slow query if it's not reported... must be a view update problem.

Comment 7

[Marco Bonardo [:mak]]

just to check, you may try a db cleanup through https://addons.mozilla.org/firefox/addon/places-maintenance/

Comment 8

[(mostly gone) XtC4UaLL [:xtc4uall]]

FWIW, confirmed with Mozilla/5.0 (Windows NT 6.1; WOW64; rv:26.0) Gecko/20100101 Firefox/26.0 ID:20130810030206 CSet: c5946a8bcd5b with Sync enabled on 2 different Boxes.

Comment 9

[webmaster]

I confirm this on a different platform with Firefox 26.0

Issue is precisely as Thomas Wolff descriped (Overview, Steps to Reproduce, Actual Results and Expected Results).

Build Date & Platform:

 - Firefox 26.0 on Arch Linux x86_64

Additional Informations:

 - 8500 bookmarks
 - 4 extensions total
 - Bookmarks cleaned of dupes
 - Have installed and runned Places-maintenance, did a full maintenance, exited and restarted Firefox
 - about:telemetry is not available for Firefox 26

 - While Sync is running, any operation in the Library takes 10-20 sec, e.g. deleting a bookmark's folder (whatever the folder has one or more bookmarks). Firefox CPU usage gets over 100% during that time.
 - Stopping Sync (removing the device from Sync) and all these operations takes no time at all.

Temporary solution: Will stop Sync and stop acting on the other Firefox profiles's bookmarks while I reorganize my Bookmarks library, then reconnect to Sync. Note: I have a few hundred operations to do on the library, which would add ~500 x 20 sec = 2.4 H to the job ":-o

Comment 10

[Mark Banner (:standard8)]

A lot has changed in the last four years wrt Sync and bookmarks, and a lot of it is performance related. I also use sync, and I've not seen this happening. Hence I'm going to mark this as works for me.

If this is still happening for people, please file a new bug. We have profiling tools now where we can also ask you to get some information that'll give us a better indication as to what is happening.