User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/534.30 (KHTML, like Gecko) Chrome/12.0.742.100 Safari/534.30 Build Identifier: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20100101 Firefox/5.0 It really looks like Firefox is busy-waiting for the response from weave, thus freezing the whole UI. Reproducible: Always Steps to Reproduce: 1. enter about:sync-tabs in the location bar 2. optionally enter master password Actual Results: Firefox will be very slow responding for a few seconds and then freezes up completely. After several seconds (up to a few minutes), Firefox will respond normally again. Until you right-click and choose to refresh. Expected Results: Normal responsiveness. The amount of open tabs may be an issue. On my Notebook Firefox currently has more than 50 open tabs and more than 70 for my PC. Both are in the Weave.

Moving to New status. I did see this a couple weeks ago, but was not able to easily reproduce it. Needs further investigation.

Thanks! If you need any more info, just ask away. I'd really love to have this fixed :) It's still happening in the most recent Firefox with sync 1.7 by the way. For me it's reproducible every time, and with every single addon (except sync) disabled. There are actually news: It now pops a script execution message stating that the script is taking to long to execute/is unresponsive. These are the line of code it reports (about:sync-tabs opened multiple times): resource://gre/components/nsSessionStore.js:2111 resource://gre/components/nsSessionStore.js:2112 I'll try it a few more times until the evening, as I'm pretty sure that the first time (where I didn't copy the script/line) it didn't report nsSessionStore.js but a different file, so that might offer some insight too.

I have just been able to reproduce the error on another file. Though I'm not sure whether it helps you: resource:///modules/services-sync/engines/tabs.js:147 Firefox 6.0.2 now.

(In reply to e.watcha from comment #3) > resource:///modules/services-sync/engines/tabs.js:147 That implies that either Svc.Session.getBrowserState(), or JSON.parse(), is hanging.

Just updated to Firefox 7, it's still happening. though when I opened sync-tabs, for one or two minutes nothing happened at all and UI responded normally, so I did right-click>refresh. Then it froze for about 2 minutes. I can also tell you that it's a busy wait, as firefox maxes out one core

Tried it on mobile firefox just now, and there it shows the tabs after less than 10s without any hangs

Thanks for letting us know. jbonacci: over to you to decide what to do with this :D

I have no idea what to do with this. I can no longer reproduce this on FF 6.0.2 (I have not yet upgraded to 7.x). I tried syncing of decent numbers of tabs in FF across Mac, Windows, and Linux. My longest lag time was about 5 seconds. And, I have never seen the pop-up. I will work with tracy next week during the next s-c branch work to see if we can reproduce this with 100+ tabs.

OK. QA has banged on this for 2 days using Firefox 7 and newer. We can not reproduce this issue.

Hmmm. I will set up a new sync user and multiple firefox profiles to test this myself... In the meantime, is there a sync server I can ping to find out if it's "just" a latency issue?

I quite accidentally happened to find this Bug 669034 - Could this be related? The sessionstore.js is about 4MB . It would certainly explain why Firefox "normally" reports nsSessionStore.js as hanging. The only explanation I can think of is that retrieving the tabs causes firefox to repeatedly store the session (every retrieved tab??) but I have no idea why it should do that Btw: I have run into a wall in trying to recreate the hangs due to the current sync server problems, I'll build the testing profile(s) when things cool down...

session store could be in play, but then it wouldn't be a sync bug. Please be sure the browser is totally finished startup before attempting to test this. Sync waits for the browser to do it's stuff before getting the tabs list from the cloud. Yes, it's a list, not single tabs.

I did some more testing the last days, here's my setup. * Firefox 7.0.1 * 3 Firefox Profiles (Developer, Developer2, Developer3) * All added to sync * No Addons Profile Developer: * In this I tried to maximize sessionstore.js size * 49 open Tabs * 750 KB sessionstore.js * 4 seconds hang on about:sync-tabs Profile Developer2: * This originally only had one tab. I didn't see the problem with one tab on either profile, so here I increased the amount of tabs without going for sessionstore.js size (increasing that one is actually quite difficult and not easily predictable, as you see on the sessionstore.js size) * 51 open Tabs (I really counted them ;)) * 1.5 MB sessionstore.js * 5 seconds hang on about:sync-tabs Profile Developer3: * I created this after I managed to get a hang on one of the other profiles, to make sure it has to do with the profile and most likely sessionstore.js size * 1 Open tab (about:synt-tabs) * 2 KB sessionstore.js * NO hang on about:sync-tabs (even though it shows the longest list of open tabs) No execution time error yet on any of those. What I think plays into this is: "Decent" local sessionstore.js size (or number of tabs?) is mandatory for the hang to happen, however, it won't hang (noticeably) if the page shows only a few tabs. Increasing the number of remote tabs then increases the hang time. from various bugs I read that at least a part of the sessionstore saving happens in the ui thread, thus hanging the in Mozilla-Central\browser\base\content\aboutSyncTabs.xul, an ui element called "richlistbox" is used, for which I was unable to find the source. My current bet is that this is treated as an input element by the saving routine, thus causing a session save on _every_ insert. Another observation plays into this: When (on my main profile) the script execution time error is shown, the page will update to show a few tabs that obviously have been processed up to that point. (5-10 tabs)

I just experienced the same issue with an unresponsive script dialog. It hangs in SS._serializeHistoryEntry() probably related to the whole JSON encoding. I'm not sure though why session store does all these things just when visiting about:sync-tabs?

(In reply to Tim Taubert [:ttaubert] from comment #14) > I just experienced the same issue with an unresponsive script dialog. It > hangs in SS._serializeHistoryEntry() probably related to the whole JSON > encoding. I'm not sure though why session store does all these things just > when visiting about:sync-tabs? I think it triggers a tab sync, which goes through session restore. If you can narrow down what tab/history entry the hang is happening in, that would be helpful!

I have been experiencing the same issues for a long time. I could reproduce the hang everytime i use Tab Sync from other computers.

I get about an eight-second hang during initial load of about:sync-tabs. My session store is about 800KB, with a hundred or so tabs open in a few windows. It's possible that my patch in Bug 691232 will have some effect on this, but if it comes down to synchronous IO on the main thread, there's not much we can do. /cc sdwilsh for the lulz.

Thanks for still taking an interest in this. Just to clarify this (@:zpao): There has to be something else going on in the main ui thread. A single session store cycle alone would not cause such a long hang in the main ui thread.

(In reply to Edward from comment #18) > Just to clarify this (@:zpao): There has to be something else going on in > the main ui thread. A single session store cycle alone would not cause such > a long hang in the main ui thread. I completely agree that it shouldn't. If it were, those hangs would be happening regularly throughout the session, but Tim mentioned it hanging in SS._serializeHistoryEntry. He may have hit a related issue.

Any news on this? I am still experiencing the same issues. It is like Sync isn't even ready for production use. Simple Scrolling up and down will make huge CPU spike. Chrome Hangs, etc.... OR will super snappy fix this ? https://bugzilla.mozilla.org/show_bug.cgi?id=718121

Bug 691232 (which has a 3 month old fix that fell through the cracks until I reviewed it a few minutes ago) might fix things. Let's get that landed and see if that fixes things.

about:sync-tabs has been deprecated. Better synced tabs UI has been implemented in a menu panel (bug 1201331) and sidebar (bug 1210586).