[b2g] Session Restoring of WebApps
The problem of low-memory devices of B2G is killing apps very often to release memory for the foreground app. It makes background apps lost their context, and being restarted for next launch. The problem is user would like to keep the states of apps when they revisit the app next time. So, we need a way to restore the states of apps being killed. One of ideas is to leverage the unload event and the sessionStorage API. Before the app process was killed, an unload event would be dispatched to the document. The app save its state on the sessionStorage in the event handler, so it could be restored for next time of launching. When a process is being killed, the content process tries to dispatch an unload event to the document. If the document handles the event, the B2G assume it is session aware, and will save the states, and restore itself next time. So, if the unload event is handled, the content of sessionStorage and cookie are sent to the b2g process before the process being dead. Next time, the user revisit the app, the sessionStorage and cookie are restored from the data at the b2g process. The app could restore it's state from the data in the sessionStorage and cookie. For best side of this approach is that we could keep the app being killed in the card view, and restore it to the state before being killed while the user revisit it next time. It provides better experience to the user. The problem is, I know, we are unlikely to encourage people to use sessionStorage or cookie as a synchronize API. Is there any other option? Please give me feedbacks. -- Sinker -- 天教懶漫帶疏狂 ___ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g
Re: [b2g] Session Restoring of WebApps
How about using Local storage to store application states. I am not sure if it wont kill the app to free the resources. But I would still love to see the results of using local storage instead of session storage. *Prateek Jadhwani* www.prateekjadhwani.com On Thu, Mar 27, 2014 at 11:33 AM, Thinker K.F. Li wrote: > The problem of low-memory devices of B2G is killing apps very often to > release memory for the foreground app. It makes background apps lost > their context, and being restarted for next launch. The problem is user > would like to keep the states of apps when they revisit the app next > time. So, we need a way to restore the states of apps being killed. > > One of ideas is to leverage the unload event and the sessionStorage > API. Before the app process was killed, an unload event would be > dispatched to the document. The app save its state on the > sessionStorage in the event handler, so it could be restored for next > time of launching. > > When a process is being killed, the content process tries to dispatch an > unload event to the document. If the document handles the event, the > B2G assume it is session aware, and will save the states, and restore > itself next time. So, if the unload event is handled, the content of > sessionStorage and cookie are sent to the b2g process before the process > being dead. Next time, the user revisit the app, the sessionStorage and > cookie are restored from the data at the b2g process. The app could > restore it's state from the data in the sessionStorage and cookie. > > For best side of this approach is that we could keep the app being > killed in the card view, and restore it to the state before being killed > while the user revisit it next time. It provides better experience to > the user. > > The problem is, I know, we are unlikely to encourage people to use > sessionStorage or cookie as a synchronize API. Is there any other > option? > > Please give me feedbacks. > > -- > Sinker > -- > 天教懶漫帶疏狂 > ___ > dev-b2g mailing list > dev-b2g@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-b2g > ___ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g
Re: [b2g] Session Restoring of WebApps
On 3/27/14, 8:33 AM, Thinker K.F. Li wrote: > The problem is, I know, we are unlikely to encourage people to use > sessionStorage or cookie as a synchronize API. Is there any other > option? Even without this kind of support, it should be considered good practice to save your session state whenever the app backgrounds. I believe that's the recommended practice on iOS and Android -- you never know when the app will get killed or terminate unexpectedly. -- Marcus Cavanaugh [:mcav] ___ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g
Re: [b2g] Session Restoring of WebApps
Prateek Jadhwani writes: > How about using Local storage to store application states. I am not > sure if it wont kill the app to free the resources. But I would still > love to see the results of using local storage instead of session > storage. The reason to suggest using session storage here instead of local storage, here, is to keep the concept of sessions. We may not like to keep states over reboot. Using session storage or local storage, it depends on how the app like to be. But, we could implement session storage in more efficent way than local storage since local storage should be persistent over the rebooting. -- Sinker -- 天教懶漫帶疏狂 ___ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g
Re: [b2g] Session Restoring of WebApps
The task that you want to perform is similar to that of using the LocalStorage, Its not about reboot. Its about restarting the app with its previous state. Right? What other solution I can think of is using another variable say an exit variable, that can be a flag set to true, when the user wants to clear the local storage session variables before initializing the app. And by default the flag can be set to false, so even when the app gets closed unexpectedly, it can load the data from Local storage. I can understand you need to change the way session Storage works in browsers (in this case Firefox OS), but changing that means changing the way session Storage works, in other works, going against the specifications. I think its an architecture related problem for the App rather than B2G. Because, not all apps would want to store the session state. *Prateek Jadhwani* www.prateekjadhwani.com On Thu, Mar 27, 2014 at 1:39 PM, Thinker K.F. Li wrote: > Prateek Jadhwani writes: > > > How about using Local storage to store application states. I am not > > sure if it wont kill the app to free the resources. But I would still > > love to see the results of using local storage instead of session > > storage. > > The reason to suggest using session storage here instead of local > storage, here, is to keep the concept of sessions. We may not like to > keep states over reboot. Using session storage or local storage, it > depends on how the app like to be. But, we could implement session > storage in more efficent way than local storage since local storage > should be persistent over the rebooting. > > -- > Sinker > -- > 天教懶漫帶疏狂 > ___ > dev-b2g mailing list > dev-b2g@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-b2g > ___ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g
Re: [b2g] Session Restoring of WebApps
On Thu, Mar 27, 2014 at 8:33 AM, Thinker K.F. Li wrote: > The problem is, I know, we are unlikely to encourage people to use > sessionStorage or cookie as a synchronize API. Is there any other > option? I would prefer to use the history/popstate APIs and see apps change URLs for each state, storing URL state via pushState[1]. This might require some system or platform changes: * A way to signal to the system, "unless explicitly triggered via an activity, save my pushState states and restore to last URL on load". * If that signal is true, then the platform saves off pushState state and URL history, and restore it once launching the app again. * Looking at the docs[1], it might be good to have firefox emit a popstate on load, to get the URL state back. [1] https://developer.mozilla.org/en-US/docs/Web/Reference/Events/popstate James ___ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g
Re: [b2g] Session Restoring of WebApps
Hi James, I will try popState api this weekend to test out this theory. Well, if we are using Routers in the app, then it should be fairly easy to drop the user to the previous state. The question is what should be use to store data that cannot be risked stored in URL, like oAuth key. Thanks *Prateek Jadhwani* www.prateekjadhwani.com On Thu, Mar 27, 2014 at 2:44 PM, James Burke wrote: > On Thu, Mar 27, 2014 at 8:33 AM, Thinker K.F. Li > wrote: > > The problem is, I know, we are unlikely to encourage people to use > > sessionStorage or cookie as a synchronize API. Is there any other > > option? > > I would prefer to use the history/popstate APIs and see apps change > URLs for each state, storing URL state via pushState[1]. > > This might require some system or platform changes: > > * A way to signal to the system, "unless explicitly triggered via an > activity, save my pushState states and restore to last URL on load". > > * If that signal is true, then the platform saves off pushState state > and URL history, and restore it once launching the app again. > > * Looking at the docs[1], it might be good to have firefox emit a > popstate on load, to get the URL state back. > > [1] https://developer.mozilla.org/en-US/docs/Web/Reference/Events/popstate > > James > ___ > dev-b2g mailing list > dev-b2g@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-b2g > ___ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g
Re: [b2g] Session Restoring of WebApps
On Thu, Mar 27, 2014 at 12:18 PM, Prateek Jadhwani wrote: > I will try popState api this weekend to test out this theory. Well, if we > are using Routers in the app, then it should be fairly easy to drop the > user to the previous state. The question is what should be use to store data > that cannot be risked stored in URL, like oAuth key. The system/platform changes would likely need to be made to make pushState a viable option. (I'll use that instead of popstate, as popstate is just the event, where pushState is the setting up of data). At least, for the use cases I think that triggered this thread: when the app gets shut down because of memory constraints. If it was a solid option, then pushState allows storing a state object that is not reflected in the URL[1]. That said, for something like an oAuth token, you may want to store more persistently in localStorage or IndexedDB, if you want it to survive more than just the one oAuth consumer interaction. [1] https://developer.mozilla.org/en-US/docs/Web/Guide/API/DOM/Manipulating_the_browser_history ___ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g
Re: [b2g] Session Restoring of WebApps
From: James Burke Subject: Re: [b2g] Session Restoring of WebApps Date: Thu, 27 Mar 2014 11:44:50 -0700 > On Thu, Mar 27, 2014 at 8:33 AM, Thinker K.F. Li wrote: >> The problem is, I know, we are unlikely to encourage people to use >> sessionStorage or cookie as a synchronize API. Is there any other >> option? > > I would prefer to use the history/popstate APIs and see apps change > URLs for each state, storing URL state via pushState[1]. > > This might require some system or platform changes: > > * A way to signal to the system, "unless explicitly triggered via an > activity, save my pushState states and restore to last URL on load". > > * If that signal is true, then the platform saves off pushState state > and URL history, and restore it once launching the app again. > > * Looking at the docs[1], it might be good to have firefox emit a > popstate on load, to get the URL state back. > > [1] https://developer.mozilla.org/en-US/docs/Web/Reference/Events/popstate > I suggest to let webapp itself to decide if saving & restoring states. For B2G, sysapp decides to restoring a session or not while the user revisiting an app. For Firefox, it is brower to make a decision. So, we need a way (an API) that sysapp to signal the platform if to save and restore session data for an app while the sysapp launch the app. > James ___ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g
Re: [b2g] Session Restoring of WebApps
On Thu, Mar 27, 2014 at 1:23 PM, Thinker K.F. Li wrote: > I suggest to let webapp itself to decide if saving & restoring states. > For B2G, sysapp decides to restoring a session or not while the user > revisiting an app. For Firefox, it is brower to make a decision. > > So, we need a way (an API) that sysapp to signal the platform if to > save and restore session data for an app while the sysapp launch the > app. I still think pushState fits in this definition. It is already provided by the platform, and also gets apps to think in terms of addressable URLs for UI states (useful for other desires for web apps, like bookmarking a jump point into an app), and it allows a chain of states to be saved, which is useful if the app is killed, and user wants to be back in the UI flow once restored. James ___ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g
Re: [b2g] Session Restoring of WebApps
From: James Burke Subject: Re: [b2g] Session Restoring of WebApps Date: Thu, 27 Mar 2014 13:23:58 -0700 > On Thu, Mar 27, 2014 at 1:23 PM, Thinker K.F. Li wrote: >> I suggest to let webapp itself to decide if saving & restoring states. >> For B2G, sysapp decides to restoring a session or not while the user >> revisiting an app. For Firefox, it is brower to make a decision. >> >> So, we need a way (an API) that sysapp to signal the platform if to >> save and restore session data for an app while the sysapp launch the >> app. > > I still think pushState fits in this definition. It is already > provided by the platform, and also gets apps to think in terms of > addressable URLs for UI states (useful for other desires for web apps, > like bookmarking a jump point into an app), and it allows a chain of > states to be saved, which is useful if the app is killed, and user > wants to be back in the UI flow once restored. I have no favor of session storage or pushState. My point is no mater how apps save and restore states, it is up to apps them-self. But, apps should not care about if history or session storage would be restored or not. It is up to the sysapp or the browser. The sysapp decides if to restore session data (session storage and history) by what UX it would like to provide. So, there is no additional API for apps, but new APIs, or API changes, for the sysapp. > > James ___ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g
Re: [b2g] Session Restoring of WebApps
Hi Thinker Li, Well lets say that this api exists, I know it doesnt, but lets just say it now exists, Could you explain more about how are you planning to interact with this api. how you are planning to store and restore data from session back into the app. And what other parameters are you planning to put into that api. Thanks *Prateek Jadhwani* www.prateekjadhwani.com On Thu, Mar 27, 2014 at 4:39 PM, Thinker K.F. Li wrote: > From: James Burke > Subject: Re: [b2g] Session Restoring of WebApps > Date: Thu, 27 Mar 2014 13:23:58 -0700 > > > On Thu, Mar 27, 2014 at 1:23 PM, Thinker K.F. Li > wrote: > >> I suggest to let webapp itself to decide if saving & restoring states. > >> For B2G, sysapp decides to restoring a session or not while the user > >> revisiting an app. For Firefox, it is brower to make a decision. > >> > >> So, we need a way (an API) that sysapp to signal the platform if to > >> save and restore session data for an app while the sysapp launch the > >> app. > > > > I still think pushState fits in this definition. It is already > > provided by the platform, and also gets apps to think in terms of > > addressable URLs for UI states (useful for other desires for web apps, > > like bookmarking a jump point into an app), and it allows a chain of > > states to be saved, which is useful if the app is killed, and user > > wants to be back in the UI flow once restored. > > I have no favor of session storage or pushState. My point is no mater > how apps save and restore states, it is up to apps them-self. But, > apps should not care about if history or session storage would be > restored or not. It is up to the sysapp or the browser. The sysapp > decides if to restore session data (session storage and history) by > what UX it would like to provide. So, there is no additional API for > apps, but new APIs, or API changes, for the sysapp. > > > > > James > ___ > dev-b2g mailing list > dev-b2g@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-b2g > ___ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g
Re: [b2g] Session Restoring of WebApps
On 03/27/2014 01:39 PM, Thinker K.F. Li wrote: > I have no favor of session storage or pushState. My point is no mater > how apps save and restore states, it is up to apps them-self. But, > apps should not care about if history or session storage would be > restored or not. It is up to the sysapp or the browser. The sysapp > decides if to restore session data (session storage and history) by > what UX it would like to provide. So, there is no additional API for > apps, but new APIs, or API changes, for the sysapp. We also need to look if we can reuse the session storage that is used by firefox desktop. It saves history, scroll position, forms being filed, etc. I heard it now supports OOP so we could leverage it for apps iframes. I don't have a strong opinion on the topic of adding a new api for that to the system app, but I would try first to just always do session restore unless called from an activity. James, do you know if we persist the pushState() data between runs? Fabrice -- Fabrice Desré b2g team Mozilla Corporation ___ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g
Re: [b2g] Session Restoring of WebApps
From: Prateek Jadhwani Subject: Re: [b2g] Session Restoring of WebApps Date: Thu, 27 Mar 2014 17:28:48 -0400 > Hi Thinker Li, > > Well lets say that this api exists, I know it doesnt, but lets just say it > now exists, Could you explain more about how are you planning to interact > with this api. how you are planning to store and restore data from session > back into the app. And what other parameters are you planning to put into > that api. For apps, they persist their states using session storage, local storage, pushState, or cookie. Whatever they use to save states, |unload| event would be dispatched to the documents of apps if sysapp decide to save session state of an app. For the sysapp, it pass two addintional parameters, save_session_state and restore_session_state, boolean values, to launch an app. save_session_state tells gecko to keep session data while the app is going dead. restore_session_state tells gecko to launch the app with the previous saved session data. ___ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g
Re: [b2g] Session Restoring of WebApps
Thinker, I would suggest making a library to do all that, and do all that stuff. I mean on the Gaia end, rather than going for B2G. And then, this library could be used by system app to do what you want to do. I would like to know your reasoning for creating an api in B2G rather than Gaia. Because I do agree with with Fabrice, creating an api just for this task might not be the proper way to achieve this goal. It might be a way, but not a proper one. Thanks *Prateek Jadhwani* www.prateekjadhwani.com On Thu, Mar 27, 2014 at 6:08 PM, Thinker K.F. Li wrote: > From: Prateek Jadhwani > Subject: Re: [b2g] Session Restoring of WebApps > Date: Thu, 27 Mar 2014 17:28:48 -0400 > > > Hi Thinker Li, > > > > Well lets say that this api exists, I know it doesnt, but lets just say > it > > now exists, Could you explain more about how are you planning to interact > > with this api. how you are planning to store and restore data from > session > > back into the app. And what other parameters are you planning to put into > > that api. > > For apps, they persist their states using session storage, local > storage, pushState, or cookie. Whatever they use to save states, > |unload| event would be dispatched to the documents of apps if sysapp > decide to save session state of an app. > > For the sysapp, it pass two addintional parameters, save_session_state > and restore_session_state, boolean values, to launch an app. > save_session_state tells gecko to keep session data while the app is > going dead. restore_session_state tells gecko to launch the app with > the previous saved session data. > ___ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g
Re: [b2g] Session Restoring of WebApps
On 03/27/2014 03:51 PM, Prateek Jadhwani wrote: > Thinker, > > I would suggest making a library to do all that, and do all that stuff. > I mean on the Gaia end, rather than going for B2G. And then, this > library could be used by system app to do what you want to do. > > I would like to know your reasoning for creating an api in B2G rather > than Gaia. Because I do agree with with Fabrice, creating an api just > for this task might not be the proper way to achieve this goal. It might > be a way, but not a proper one. Note that I'm not advocating for a gaia side solution. That would probably not perform as well as the session restore we build in gecko. I just said that I'm not convinced if we need any api at all. Fabrice -- Fabrice Desré b2g team Mozilla Corporation ___ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g
Re: [b2g] Session Restoring of WebApps
Lol Fabrice, I know what you are saying. But Library != api We already have the api. What I understand (correct me if I am wrong ) that Thinker doesnt want to use the sessionStorage and/or LocalStorage apis, neither wants to manage the variables directly. He wants something in between that does it automatically. Which already have the logic to restore when the app crashes. So, what I am suggesting is use a Library that does that, instead of an api. Secondly, every app might not want to do it, so we can limit the library to a single app, instead of calling it for every app in system api. But then again, we need to respect what Thinker requires for his project as well. He might be doing something where he might require it for every app. Thats why I want hear his reasoning for adding an api instead of a library call. *Prateek Jadhwani* www.prateekjadhwani.com On Thu, Mar 27, 2014 at 6:57 PM, Fabrice Desré wrote: > On 03/27/2014 03:51 PM, Prateek Jadhwani wrote: > > Thinker, > > > > I would suggest making a library to do all that, and do all that stuff. > > I mean on the Gaia end, rather than going for B2G. And then, this > > library could be used by system app to do what you want to do. > > > > I would like to know your reasoning for creating an api in B2G rather > > than Gaia. Because I do agree with with Fabrice, creating an api just > > for this task might not be the proper way to achieve this goal. It might > > be a way, but not a proper one. > > Note that I'm not advocating for a gaia side solution. That would > probably not perform as well as the session restore we build in gecko. I > just said that I'm not convinced if we need any api at all. > > Fabrice > -- > Fabrice Desré > b2g team > Mozilla Corporation > ___ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g
Re: [b2g] Session Restoring of WebApps
From: Prateek Jadhwani Subject: Re: [b2g] Session Restoring of WebApps Date: Thu, 27 Mar 2014 18:51:13 -0400 > Thinker, > > I would suggest making a library to do all that, and do all that stuff. I > mean on the Gaia end, rather than going for B2G. And then, this library > could be used by system app to do what you want to do. > > I would like to know your reasoning for creating an api in B2G rather than > Gaia. Because I do agree with with Fabrice, creating an api just for this > task might not be the proper way to achieve this goal. It might be a way, > but not a proper one. I am not sure how the sysapp controls life-cycle of sessions in this way, a library, except you don't like the sysapp to control life-cycle of sessions. The api here is for customization of UX. If we all agree that life-cycle of sessions should not be a part of device's UX, then we don't need the api. ___ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g
Re: [b2g] Session Restoring of WebApps
Hi, In case not every one knows, we are trying to keep a crashed app in task manager and restore it with the latest url. It’s implemented already, see https://bugzilla.mozilla.org/show_bug.cgi?id=935750 Someone call it ‘zombie app’, but I call this ‘suspending app’ to reflect it’s suspending. I am not familiar with how gecko implements session restore, but as James Burke said, it’d be easy to keep the state with url in system app and restore the url in the app resuming process. If people dislike to use pushState, and there’s an API for system app to invoke before suspending/resuming I’d like to implement that which should be easy with this feature. — Alive C. Kuo, Senior Software Engineer, Firefox OS, MoCo. Taipei Office al...@mozilla.com Thinker K.F. Li 於 2014/3/28 上午7:20 寫道： > From: Prateek Jadhwani > Subject: Re: [b2g] Session Restoring of WebApps > Date: Thu, 27 Mar 2014 18:51:13 -0400 > >> Thinker, >> >> I would suggest making a library to do all that, and do all that stuff. I >> mean on the Gaia end, rather than going for B2G. And then, this library >> could be used by system app to do what you want to do. >> >> I would like to know your reasoning for creating an api in B2G rather than >> Gaia. Because I do agree with with Fabrice, creating an api just for this >> task might not be the proper way to achieve this goal. It might be a way, >> but not a proper one. > > I am not sure how the sysapp controls life-cycle of sessions in this > way, a library, except you don't like the sysapp to control life-cycle > of sessions. > > The api here is for customization of UX. If we all agree that > life-cycle of sessions should not be a part of device's UX, then we > don't need the api. > ___ > dev-b2g mailing list > dev-b2g@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-b2g ___ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g
Re: [b2g] Session Restoring of WebApps
On Tue, Apr 8, 2014 at 9:24 AM, Alive wrote: > In case not every one knows, we are trying to keep a crashed app in task > manager and restore it with the latest url. It’s implemented already, > see https://bugzilla.mozilla.org/show_bug.cgi?id=935750 > > Someone call it ‘zombie app’, but I call this ‘suspending app’ to reflect > it’s suspending. > > I am not familiar with how gecko implements session restore, > but as James Burke said, it’d be easy to keep the state with url in system > app and restore the url in the app resuming process. I was curious to see how the URL restoration worked, what its limits were, so I created a test app that uses pushState with URL fragment ID changes. It seems like perhaps that bug is just for a crash scenario and not an OOM? I could not trigger a case where it would resume from last URL with the fragment ID, but I was mostly testing an OOM case. But bigger picture for me, along the thoughts in this thread, is to have a way for the history state to be maintained, such that this sample app could relaunch at its last state/URL and clicking the < back button inside the app would continue to work for the history state it had previously. I can see where there are complications for the system to know when to restore this and when to start fresh based on user action. Hopefully the test app could help if someone wanted to play with changes to get it to work. If there are bugs already filed for this, or other discussions related to it, feel free to point me in the right direction. App zip: http://jrburke.com/work/gaia/fxos-url-state.zip Can be installed using about:app-manager: https://github.com/jrburke/gaia-dev-zip#for-the-ux-person Source code: https://github.com/jrburke/fxos-url-state James ___ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g
