bugzilla.mozilla.org will be intermittently unavailable on Saturday, March 24th, from 16:00 until 20:00 UTC.

Weave should not load / do anything until it absolutely needs to



Cloud Services
9 years ago
8 years ago


(Reporter: thunder, Assigned: mconnor)


Bug Flags:
blocking-weave1.0 +

Firefox Tracking Flags

(Not tracked)



(1 attachment)



9 years ago
In order to make sure Weave has minimal impact on Ts, it should load/initialize/do an initial sync as late as possible.

Beware: Weave tracks changes in tracker objects.  We want those to initialize late too because they often require registering an observer object with another component (e.g. Places), thus forcing it to initialize as well.  But at the same time, not tracking changes might lead to dataloss.

Places sends out a notification when it initializes, something we might listen for.
Flags: blocking-weave1.0+


9 years ago
Priority: P1 → P2


9 years ago
Priority: P2 → P1


9 years ago
Assignee: nobody → mconnor

Comment 1

9 years ago
Created attachment 402465 [details] [diff] [review]
delays init until all tabs are loaded, cleans some stuff up

UI pieces (i.e. about:weave) will need to check if Weave.Service.status.service == STATUS_DELAYED before trying to do anything.
Attachment #402465 - Flags: review?(edilee)

Comment 2

9 years ago
Comment on attachment 402465 [details] [diff] [review]
delays init until all tabs are loaded, cleans some stuff up

>+++ b/source/modules/service.js
>@@ -289,14 +289,67 @@
>+  // make sure we're not still loading a bunch of tabs.
>+  _readyForStartup: function WeaveSvc__readyForStartup() {
>+    switch (Svc.AppInfo.ID) {
>+      case FENNEC_ID:
>+        return true; // FIXME
I don't think fennec has session restore right now, and "sync on idle" needs to wait for the screen to go dim. But I suppose people running in to issues on Firefox startup aren't actually syncing but auto-logging-in.

>+      case FIREFOX_ID:
>+          if (tabbrowser.mIsBusy)
>+            return false;
Is this just to short circuit the looping over tabs? mIsBusy is only for the currently selected tab, no?

>+          for (let i = 0;i < tabbrowser.mTabs.length;i++)
>+            if (tabbrowser.mTabs[i].hasAttribute("busy"))
>+              return false;
This potentially would always return false on some slow loading page or user activity way past startup. A tab is marked busy anytime it has network activity, so does that include any iframes or continuous connections?

After looking at the patch, I'm thinking maybe we can just have a function that return a number of seconds to delay startup (once). So for Firefox, it can count the number of busy tabs across all windows and wait... a second for each. Maybe even cap it on both ends with a minimum of 5 seconds and max of a minute. ?

Comment 3

9 years ago
(In reply to comment #0)
> Places sends out a notification when it initializes
places-init-complete gets sent before sessionstore-windows-restored, so Weave is already triggering on the later notification. If we're okay with missing out on potentially some early-in-session page visits and/or bookmark changes, etc. we can arbitrarily delay ourselves some seconds.

Comment 4

9 years ago
Land some initial statusbar UI bits of bug 513944  and remove unused/debug code. 

Basically everything except service.js changes with some additional code removal + add comments.

Comment 5

9 years ago
Weave already triggers on a late notification and puts itself on the event loop, so just additionally delay startup based on the number of open tabs (which will all be busy at startup).
Last Resolved: 9 years ago
Resolution: --- → FIXED


8 years ago
Attachment #402465 - Flags: review?(edilee)
You need to log in before you can comment on or make changes to this bug.