Open Bug 1614465 Opened 2 months ago Updated 9 days ago

De-couple ASRouter initialization from Activity Stream


(Firefox :: Messaging System, task, P1)




Firefox 75
76.2 - Mar 23 - Apr 5
Tracking Status
firefox74 --- unaffected
firefox75 --- fix-optional
firefox76 --- affected


(Reporter: mconley, Assigned: bigiri)


(Blocks 1 open bug)



(1 file)

ASRouter grew out of work from the Activity Stream team, but at this point seems to be a pretty distinct component.

Bug 1614351 and its dependencies hopes to eventually rearchitect how about:home starts up a bit. One of the first things we'd like to do is make it so that ASRouter doesn't depend on Activity Stream for initialization.

We'll still need it so that ASRouter can send snippets to about:home, but there should be a well-defined API for this... I'm not sure having ASRouter send messages down directly through the message channel is the right move. Perhaps ASRouter can talk to AboutNewTabService or something, and then AboutNewTabService does the job of sending the update down to all of the about:home pages.

hey mike, were you planning on working on this? we are doing some refactoring with separating about:welcome from newtab that might overlap

Flags: needinfo?(mconley)

I'm hoping bigiri can work on it soon - we're meeting today about it, and then he'll likely reach out to your team to coordinate.

Flags: needinfo?(mconley)
Assignee: nobody → bigiri
Iteration: --- → 75.2 - Feb 24 - Mar 8
Priority: -- → P1
Target Milestone: --- → Firefox 75

From our chat, it seems like the first step is removing the blocking initialization dependency of ASRouter from new tab page's startup path. So we need to find an appropriate place to initialize and communicate with ActivityStream/new tab modules.

For reference, this is how ASRouter currently initializes at startup:

  1. browser.js _delayedStartup
  2. AboutNewTabService.jsm constructor
  3. AboutNewTab.jsm onBrowserReady
  4. ActivityStream.jsm init
  5. ASRouterFeed.jsm enable
  6. ASRouter init

The last step 6 actually initializing ASRouter takes parameters for the channel (to communicate with content pages), indexeddb storage (to persist data), and dispatch function (to send actions to activity stream).

Ideally somehow we just straight to step 6 to not rely on any of the other new tab startup behavior. It seems likely the entry point will be similar to existing step 1 as that's where many other things get initialized, but potentially we can delay even more.

I believe this specific bug should focus on breaking the dependency and followup bugs will move various pieces out of the main process. And hopefully with the first step done, new tab page can start sooner without explicitly blocking on ASRouter related code (although might be indirectly delayed when competing for cpu/disk resources).

Iteration: 75.2 - Feb 24 - Mar 8 → 76.1 - Mar 9 - Mar 22

Work in Progress. No tests have been altered or written yet.

Iteration: 76.1 - Mar 9 - Mar 22 → 76.2 - Mar 23 - Apr 5
You need to log in before you can comment on or make changes to this bug.