Closed Bug 1488813 Opened Last year Closed Last year

Migrating Pocket off any bootstrap code


(Firefox :: Pocket, enhancement)

Not set



Firefox 64
Tracking Status
firefox64 + fixed


(Reporter: shell, Assigned: thecount)




(1 file)

A discussion has happened in email about porting - just moving to a bug for tracking and prioritization.

Who is assigned to own the migration before boostrapping goes away?  

The timeline is below:

Bootstrapped code will start being removed from 65 Nightly after October 22 (completed before Dec 11).  Bootstrapped add-ons won't work in 65 Beta (on Dec 11) or 65 Release (on Jan 29th).
Adding that I would really like to change the way localization is managed right now for this add-on (e.g. manual import and export).
We are tracking this and moving some steps forward to accommodate this change. Adding Scott Downe, who is owner for Pocket team.

Is this bug the proper place to post updates as we go? Is the email discussion the one I started a few weeks ago? Or something else?

Re: localization. We should create a separate ticket to track that - it will not be a part of this migration, but certainly something for us to improve in a follow-on.
Flags: needinfo?(sescalante)
I spoke with Karlof about this some time ago, but we haven't heard anything else, so this bug is filed as the best place for tracking the landing of that code and handling its review (I assume aswan would be the intended reviewer) for 64. And of course aswan is on point for any assistance/guidance.

[I didn't want to assume what "merging into Firefox" meant, but considering how Pocket currently gets integrated to the codebase, it wasn't clear that the bootstrapped code was being removed ;) .]

I don't know if we need updates so much as keeping track overall. Shell is tracking all of these migrations off bootstrapped code (the parent bug) for 64 at the EPM level, so as long as there's some way for Pocket's PM to keep her updated, that doesn't need to go here. Shell -- do you have a preference?
Hi Matt,

We can discuss in email, or this bug, or a vidyo meeting if discussing directly with engineering seems like a better option.  Whatever format works best.  You can email me at if you'd like me to set something up.  

We want to make sure Pocket will not rely on bootstrapped code when we start removing it with Firefox 65.  All add-ons should be porting for Firefox 64, to avoid issues when the code starts going away in Nightly 65 and Beta 65.

There had been an email thread that we can continue to discuss.  It is our understanding that the current add-on relies on bootstrap code (we may be wrong).  Merging that add-on (if it is still using Bootstrap APIs) into the tree, would still break when the underlying Bootstrap APIs go away.
Flags: needinfo?(sescalante) → needinfo?(matt)
Flags: needinfo?(matt)
Shell -

Thanks for the follow-up. 

Scott Downe is going to be taking the lead here and starting to dig in end of this week/next. We've discussed approach with Kate Hudson who shared similar work the Activity Stream did. 

We are aware of the timeline and will be working towards that - we will reach out as Scott gets going with any questions. We also have setup a Slack channel at #pkt-addon-migrate and will be sending a "Intent to Implement" email out. We will use this as our main tracking ticket and update progress as well.

Looking forward to moving this forward!
Thanks for the update Matt.  I'm not sure how closely you all track the Firefox development process but be aware that we have a "soft freeze" about 2 weeks before the final Nightly->Beta uplift, that means this ought to land by about Oct. 8.  There *shouldn't* be any big barriers to getting it done but with anything this size, I would urge you to leave plenty of time to sort through any surprises that come up along the way...
Andrew - thanks for the note. We had discussed the "soft freeze" but for some reason we thought it was the week after :) Good to know re: Oct 8th. (Although documentation here - - also suggests its 1 week, not 2?) 

In any event, we had some other high priority items that we are getting clear of, so will be moving this forward.
Assignee: nobody → sdowne
Hm.  Well during the last cycle this was the schedule:!topic/

So 8/23 to 9/4 == 12 days, somewhere between 1-2 weeks. has the dates for 64, but the short version is the soft freeze is set to start on Oct 15, until Oct 22 when nightly becomes 65.
Hi Scott,

Is there anyone that needs to review this patch?  I see it went up - but not any update on if it will be landed.
Flags: needinfo?(sdowne)
It's got a reviewer, but I'm also working out try errors. I have it close, only a few fails, but it's slow going.

I think at this point I'm trying to find the opportune to call the init function from inside nsBrowserGlue.js.

Any advice on finding another place, that basically happens at the same time that addons happen, that would be appreciated.

I'm trying two builds on try now:
Flags: needinfo?(sdowne)
OK, I've tried a bunch of builds, and cannot seem to get the tests to pass on try, and cannot seem to get them to fail locally. The patch works locally too. So I'm not able to reproduce anything.

I initially thought it was about WHEN I call my new init in the patch was the key to making this work, but not I'm thinking there is something in the init that times out on try, and moving it just causes it to timeout in different spots, thus producing different test failures? I think the root of the issue is getting it to finish running the new pocket init on try.

Any advice is appreciated...
Shell - any thoughts on who we can ping to help Scott here? We believe we are close, but need a little support to get this tested and landed.
Flags: needinfo?(sescalante)
Scott, I can try to help you with the tests.  Do you want to try to go over these interactively (ie irc/slack/vidyo)?  That might be more efficient, at least for the first pass...
Flags: needinfo?(sescalante)
What's the right thing to do with the localization files here? Right now they are in browser/extensions/pocket/locale, should they be moved browser/locales/en-US/chrome/browser? What happens to the translations?
Flags: needinfo?(francesco.lodolo)
(In reply to Kate Hudson :k88hudson from comment #17)
> What's the right thing to do with the localization files here? Right now
> they are in browser/extensions/pocket/locale, should they be moved
> browser/locales/en-US/chrome/browser? What happens to the translations?

Right now Pocket is localized outside of mozilla-central

We should move it into browser/locales/en-US/chrome/browser (or a subfolder).

We did it for Activity Stream in bug 1457223. I'm pretty sure we created a script for it, but I'm failing to find it. Redirecting NI to Pike for that, while I keep searching.
Flags: needinfo?(francesco.lodolo) → needinfo?(l10n)
Never mind, found it

I suggest to take a look at bug 1457223, there are a bunch of things to look at (l10n.ini, l10n.toml), coordinate landing, etc.
Flags: needinfo?(l10n)
@flod is this something that's a blocker or could it be done in a followup ticket? Either way I think I'll need help :)
Flags: needinfo?(francesco.lodolo)
(In reply to Scott [:thecount] Downe from comment #20)
> @flod is this something that's a blocker or could it be done in a followup
> ticket? Either way I think I'll need help :)

It's something my team would take care of. We only need to define in which path those strings should live. Feel free to open a new bug and assign it to me.

We can also do it before we move the code, since nobody is actually importing strings from pocket-l10n to mozilla-central anyway :-\
Flags: needinfo?(francesco.lodolo)
Chatting with flod, it sounds like the plan is to do the l10n related changes in another patch targeting 65.

If that's the case, I think this is ready for a final look.
Flags: needinfo?(khudson)
Starting the l10n discussion here:
Pushed by
Fixes bug 1488813 - Migrating Pocket off any bootstrap code r=ursula,k88hudson
Closed: Last year
Resolution: --- → FIXED
Target Milestone: --- → Firefox 64
Depends on: 1498914
Flags: needinfo?(khudson)
You need to log in before you can comment on or make changes to this bug.