Re: Intent to implement: NavigationController

[Nikhil Marathe]

On Wednesday, August 7, 2013 7:02:51 PM UTC-7, Ehsan Akhgari wrote:
> On Mon, Aug 5, 2013 at 3:17 PM, Nikhil Marathe wrote:
> 
> 
> 
> > On Monday, August 5, 2013 10:01:06 AM UTC-7, Mounir Lamouri wrote:
> 
> > > On 26/07/13 18:29, Ehsan Akhgari wrote:
> 
> > >
> 
> > > > We're planning to implement a prototype of the NavigationController
> 
> > >
> 
> > > > interface (see bug 898524).  We will try to get feedback from web
> 
> > >
> 
> > > > developers on the prototype and will use that feedback to change the
> 
> > spec
> 
> > >
> 
> > > > and the implementation and iterate on the API.  Our major goal for now
> 
> > is
> 
> > >
> 
> > > > coming up with a good API that is useful for the intended use cases.
> 
> >  Once
> 
> > >
> 
> > > > we're there, we will talk about plans to ship the API.  For now, all of
> 
> > >
> 
> > > > this work will be disabled for web content.
> 
> > >
> 
> > > >
> 
> > >
> 
> > > > Please let me know if you have any questions!
> 
> > >
> 
> > >
> 
> > >
> 
> > > My understanding is that we wanted to implement this feature on top of
> 
> > >
> 
> > > Event Pages. Is there any plan to implement this too?
> 
> > >
> 
> > >
> 
> > >
> 
> > > -- Mounir
> 
> >
> 
> > I'm experimenting with this. The SharedWorker patches are crucial to this,
> 
> > and I've spent some time trying to get them to work on m-c, before I can
> 
> > start working on this.
> 
> >
> 
> 
> 
> Initially I have been planning to use a SharedWorker for the prototype for
> 
> the sake of getting it ready sooner.  Nikhil, is there a bug for your work
> 
> on Event Pages?  If yes, I'd gladly follow that bug and will try to build
> 
> something on top of your work there.
> 

Right now my patch doesn't do much over bent's rebased sharedworker patch. So 
you can start with it. I've to understand some of the code and think through 
some things, after which I can start a thread here about what Event 
page/Background services will behave.

Nikhil
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement: NavigationController

[Nikhil Marathe]

There is no bug number yet, because I have about 15 lines of additional
code :)


On Thu, Aug 8, 2013 at 3:52 PM, Ehsan Akhgari wrote:

> On 2013-08-08 12:20 PM, Nikhil Marathe wrote:
>
>> On Wednesday, August 7, 2013 7:02:51 PM UTC-7, Ehsan Akhgari wrote:
>>
>>> On Mon, Aug 5, 2013 at 3:17 PM, Nikhil Marathe wrote:
>>>
>>>
>>>
>>>  On Monday, August 5, 2013 10:01:06 AM UTC-7, Mounir Lamouri wrote:
>>>>
>>>
>>>  On 26/07/13 18:29, Ehsan Akhgari wrote:
>>>>>
>>>>
>>>
>>>>>
>>>  We're planning to implement a prototype of the NavigationController
>>>>>>
>>>>>
>>>
>>>>>
>>>  interface (see bug 898524).  We will try to get feedback from web
>>>>>>
>>>>>
>>>
>>>>>
>>>  developers on the prototype and will use that feedback to change the
>>>>>>
>>>>>
>>>  spec
>>>>
>>>
>>>
>>>>>
>>>  and the implementation and iterate on the API.  Our major goal for now
>>>>>>
>>>>>
>>>  is
>>>>
>>>
>>>
>>>>>
>>>  coming up with a good API that is useful for the intended use cases.
>>>>>>
>>>>>
>>>Once
>>>>
>>>
>>>
>>>>>
>>>  we're there, we will talk about plans to ship the API.  For now, all of
>>>>>>
>>>>>
>>>
>>>>>
>>>  this work will be disabled for web content.
>>>>>>
>>>>>
>>>
>>>>>
>>>
>>>>>>
>>>
>>>>>
>>>  Please let me know if you have any questions!
>>>>>>
>>>>>
>>>
>>>>>
>>>
>>>>>
>>>
>>>>>
>>>  My understanding is that we wanted to implement this feature on top of
>>>>>
>>>>
>>>
>>>>>
>>>  Event Pages. Is there any plan to implement this too?
>>>>>
>>>>
>>>
>>>>>
>>>
>>>>>
>>>
>>>>>
>>>  -- Mounir
>>>>>
>>>>
>>>
>>>>
>>>  I'm experimenting with this. The SharedWorker patches are crucial to
>>>> this,
>>>>
>>>
>>>  and I've spent some time trying to get them to work on m-c, before I can
>>>>
>>>
>>>  start working on this.
>>>>
>>>
>>>
>>>>
>>>
>>>
>>> Initially I have been planning to use a SharedWorker for the prototype
>>> for
>>>
>>> the sake of getting it ready sooner.  Nikhil, is there a bug for your
>>> work
>>>
>>> on Event Pages?  If yes, I'd gladly follow that bug and will try to build
>>>
>>> something on top of your work there.
>>>
>>>
>> Right now my patch doesn't do much over bent's rebased sharedworker
>> patch. So you can start with it. I've to understand some of the code and
>> think through some things, after which I can start a thread here about what
>> Event page/Background services will behave.
>>
>
> I think you forgot the bug number.  :-)
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to replace Promise.jsm and promise.js with DOM Promises

[Nikhil Marathe]

(Cross posted to firefox-dev, please reply on dev.platform)

DOM Promise has been in the tree for a while, and is enabled for
ChromeWorkers and certified apps. With a couple of patches, it will achieve
conformance with the AP2 spec [1], which is what TC39 has accepted as the
bare minimum for Promises in ECMA6. It will also be available on Workers as
long as the pref is enabled. We currently have two JS promise
implementations in our codebase:
toolkit/modules/Promise.jsm
addon-sdk 
/source
/lib /
sdk
/core
/promise.js

which offer a different API and reimplement some code, one for chrome, one
for content.

My intention is:
1) Enable Promises for all chrome code.
2) Set dom.promise.enabled to true for tests
3) Migrate all users of the two promise implementations to the new style
(including tests).
4) Get rid of these two JS implementations.
The work is being tracked in Bug 939636 [2].

It would be a great help if developers who work on code using Promises
could download the patch that enables Promises in chrome and submit patches
to that bug updating code/tests.
The new spec has a different style of creating promises, which may not
interface well with callback oriented code. Feel free to ping me (nsm on
IRC) if you need help.

If there is a reason this shouldn't be done, please let me know.

At some point in the future Spidermonkey will implement Promises natively,
at which point (theoretically) all the code can simply transition to that
with no changes.

Nikhil

[1] https://github.com/domenic/promises-unwrapping
[2] https://bugzil.la/939636
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to ship DOM Promises

[Nikhil Marathe]

As off January 28, our DOM Promises implementation implements the es6
promises spec. [1]
It is feature complete, and passes the Promises/A+ tests. [2]
I intend to enable it by default this week so that it ships in Firefox 30.

Caveats:
We don't support subclassing, which is a ES6 feature, but neither does the
Chromium implementation. This does not affect the ability to use Promises
by themselves.

[1]: https://github.com/domenic/promises-unwrapping
[2]: http://domenic.me/aplus-tests-against-the-browser/

Status of other implementations:
Enabled by default in Opera 19 and Chromium 32
http://www.chromestatus.com/features/5681726336532480

Relevant bugs:
Enable Promises by default - https://bugzil.la/885333

Regards,
Nikhil
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Disabling a few mochitests this week, and upcoming changes next week to browser-chrome

[Nikhil Marathe]

On 08/26/2014 12:52 PM, Gavin Sharp wrote:
> Thanks for the update! Very helpful.
>
> For bug 1058695, it looks like bz/khuey are trying to rope in Nikhil
> to help - Nikhil, I don't know what the rest of your current workload
> looks like, but if you could help chase that bug down that would be
> very helpful.
>
I should be able to fix it tomorrow.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Cross origin communication and the navigator.connect API

[Nikhil Marathe]

(cross posted dev.b2g since this seems very relevant to it, but please keep
the discussion on dev.platform)

Hi All,

As part of the ServiceWorker initiative [1], Google is proposing a
`navigator.connect` API [2] to allow cross-origin ServiceWorker
communication. This post is mostly a notice to inform everyone of this
unofficial draft API.

This seems similar to our Inter-App communication API [3] and I'm sure the
authors and users of that API have feedback that should be incorporated in
a cross-web (non-b2g-specific) API. There also seems to be overlap with
some use-cases for Web Activities [4].

This is a good opportunity for us to influence how cross-origin messaging
is implemented at an early stage. If someone wants to drive this from
Mozilla's side, please "raise your hand".

Best,
Nikhil

[1]:
https://slightlyoff.github.io/ServiceWorker/spec/service_worker/index.html
[2]: https://github.com/mkruisselbrink/navigator-connect
[3]: https://bugzilla.mozilla.org/show_bug.cgi?id=876397
[4]: https://developer.mozilla.org/en-US/docs/Web/API/Web_Activities
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Cross origin communication and the navigator.connect API

[Nikhil Marathe]

On Wed, Dec 10, 2014 at 9:46 AM, Ehsan Akhgari 
wrote:

> On 2014-12-10 12:21 AM, Nikhil Marathe wrote:
>
>> (cross posted dev.b2g since this seems very relevant to it, but please
>> keep
>> the discussion on dev.platform)
>>
>> Hi All,
>>
>> As part of the ServiceWorker initiative [1], Google is proposing a
>> `navigator.connect` API [2] to allow cross-origin ServiceWorker
>> communication. This post is mostly a notice to inform everyone of this
>> unofficial draft API.
>>
>> This seems similar to our Inter-App communication API [3] and I'm sure the
>> authors and users of that API have feedback that should be incorporated in
>> a cross-web (non-b2g-specific) API. There also seems to be overlap with
>> some use-cases for Web Activities [4].
>>
>> This is a good opportunity for us to influence how cross-origin messaging
>> is implemented at an early stage. If someone wants to drive this from
>> Mozilla's side, please "raise your hand".
>>
>
> I am very interested in this problem, and in fact I've been thinking about
> what we should do for cross origin SW communications for a while.  :-)  I
> do support the idea but I'm not convinced that we need a specific API to
> talk to the SW (such as navigator.connect.)
>
> What I have been envisioning is allowing SWs that are registered with the
> UA to respond to cross origin fetch requests made through XHR/fetch even
> from documents that are themselves not controlled by a SW.  The reasoning I
> have for this is as follows:
>
> Currently on the Web, the defacto way that applications talk to each other
> cross origin is through XHR using CORS.  See the numerous HTTP based APIs
> that are developed by various organizations that are used by Web
> applications right now.  With service workers, we are going to have a Web
> that is usable off-line, and we can also use SWs to do things such as
> smarter caching on the client side.  The next interesting use case would be
> to enable the usage of these HTTP based APIs offline (or doing smart
> caching on the client side, etc.)
>
> I see no great reason to require Web applications to write specific code
> for this, though.  Let's say that my application XHRs into <
> https://socialnetwork.com/get/friends> in order to get the user's list of
> friends.  It would be nice to allow that request to be handled by the
> service worker registered for socialnetwork.com and give that SW control
> over whether it wants to respond to the request without going to the
> network.  This has the additional advantage that people's code and all of
> the ecosystem that they have built on top of XHR based APIs over the years
> will just work offline once the service providers get their SWs registered.
>

I like this idea. It would even be possible to create some lib that used a
bit of JS reflection to auto create fully RESTful APIs from the functions
exposed to cross-origin in the SW script. But I'm getting ahead of myself :)

The fetch() based API won't be as user friendly as postMessage() for
gossiping (where the two SWs are having an entire conversation rather than
just a couple of exchanges), but it should be easy to abstract that away
into a library too so that:

  var ipc = new LibIPC('//foo.com')
  ipc.send("/addToCart", "itemid=4").send("/useCachedCredentialsToPay",
"authToken=baz").then(function() {}, function() {})

and underneath the lib would chain calls to fetch() and deal with response
Promises accordingly and resolve the then() appropriately.

CORS can be used in lieu of event.acceptConnection().

I guess having some primitives for structured clone like behavior would be
nice. That too can be handled by use of Response.blob() and
FileReader[Sync]() on workers, but having primitives means that UAs could
optimize the structured clone behind the scenes instead of actually
creating Blobs.

(Aside: Sometimes I wish we could create a smaller rendering engine that
had no UI and ran exclusively workers and their DOM APIs and make that the
Firefox OS system process)

Nikhil
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Farcebook.messenger

[Nikhil Marathe]

Hi Till,

I think you may be confused by the way a lot of tech news sites have
announced it.

"Much like the OpenSearch standard, Mozilla’s new Social
APIlets social services
integrate into Firefox in a compelling way and makes
it easier to use the Web the way you want. The Social API includes features
like a social sidebar, toolbar notification buttons and the ability to
easily chat with your friends no matter where you are on the Web."

-
https://blog.mozilla.org/blog/2012/11/20/firefox-introduces-new-social-api-and-previews-integration-with-facebook/

"We are excited to offer a preview of our *first social integration* with
Facebook Messenger for Firefox"

which means that Facebook is the first implementor of the API. It does not
mean FF will only support Facebook
or that Facebook is being pushed onto you when you update firefox. If you
don't want it, don't visit the page
to activate it.

Best,
Nikhil

On Thu, Nov 22, 2012 at 3:32 AM, Till M  wrote:

> You just lost me as a Loyal user and promoter of Firefox for over ten
> years!
>
> Bye!
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Push Notifications feedback

[Nikhil Marathe]

On Thu, Jan 24, 2013 at 5:06 AM,   wrote:
> Hi,
>
> Are you people still working on this at mozilla.org?  I noticed that the Wiki 
> now redirects to https://wiki.mozilla.org/WebAPI/PushAPI which seems specific 
> to FirefoxOS.
>
> I am interested in implementing the feature for other web browsers as 
> extensions (+ helper javascript).

Its now this: https://bugzil.la/822712
We're working on making sure this runs on all platforms natively.

NOTE: This push notification system is not for informing the user via
badges or similar,
but to inform a running/installed webapp about updates. the webapp can
then use desktop-notifications
or similar to inform the user.

Nikhil
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform