Re: Cross origin communication and the navigator.connect API

[Jeffrey Yasskin]

I think we should be really reluctant to add a synchronous interface to an
API that has to communicate cross-process.

Feedback from your Inter-App communication and Web Activities folks would
be really great!

Jeffrey

On Tue, Dec 9, 2014 at 11:04 PM, Jake Leichtling 
wrote:

> As the draft API spec  
> currently
> stands, initial connection and ongoing communication are all asynchronous.
> This is how we have initially envisioned the API, but there isn't any major
> impediment to considering a synchronous piece if a compelling use case
> supports it.
>
> One key part of the API that remains to be sorted out is what will happen
> when a web origin attempts to connect to a Service Worker that is not
> registered. This connection attempt could either fail—perhaps without any
> indication of whether the SW was not installed or rather the connection was
> rejected for some other reason—or it could lead to downloading and
> registering the SW. Maybe this scenario necessitates UI in some cases. This
> is very much an open question.
>
>
> Jake Leichtling | Associate Product Manager ☰ Chrome Apps |
> jleichtl...@google.com | (415) 279-4508
>
> On Tue, Dec 9, 2014 at 9:34 PM, Bobby Holley 
> wrote:
>
>> This API is message-passing only, and doesn't have any synchronous
>> pieces, right?
>>
>> What, from your understanding, are the key/interesting high-level pieces
>> of this API that need to be sorted out?
>>
>> On Tue, Dec 9, 2014 at 9:21 PM, 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".
>>>
>>> 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
>>>
>>
>>
>
___
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

[David Rajchenbach-Teller]

Isn't that the same issue as Web Activities/Web Intents?

On 10/12/14 20:55, Ehsan Akhgari wrote:
>> This seems like a solvable problem.
>>
>> We could enable website A to hint to the UA that website B has a SW
>> that would be useful for A to interact with. Then the UA could somehow
>> give B an opportunity to install a SW.
> 
> That sounds like a good idea to me.
> 
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform


-- 
David Rajchenbach-Teller, PhD
 Performance Team, Mozilla



signature.asc
Description: OpenPGP digital signature
___
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

[Ehsan Akhgari]

On 2014-12-11 2:03 AM, Jonas Sicking wrote:

On Wed, Dec 10, 2014 at 6:22 PM, Alex Russell  wrote:

On Wed, Dec 10, 2014 at 5:48 PM, Ehsan Akhgari 
wrote:


On 2014-12-10 7:45 PM, Jonas Sicking wrote:


On Wed, Dec 10, 2014 at 4:22 PM, Jonas Sicking  wrote:


On Wed, Dec 10, 2014 at 1:02 PM,   wrote:


2) Users could more easily write infinite loops between SWs, since at
no point would they be guaranteed to bottom out at the network.



I'm more worried about the memory implications for low-spec devices of
the russian-doll design for SW fetches. We've avoided it thus far for these
reasons.



How does navigator.connect() address this problem?

In Ehsan's proposal SW from site A would do a fetch() which starts the
SW from site B. In the navigator.connect() proposal the SW from site A
would do a navigator.connect() which starts the SW from site B.

So the same number of SWs seem to be started, the only difference is
the API that's used to start them, no?



Hmm.. actually navigator.connect() does actually partially address this
problem.

It allows site A to talk to site B without using fetch() at all. Thus
enabling A to avoid using the A SW at all.

Though that particular goal could be reached by adding some of the
optimizations that we talked about early on in SWs design. I.e. the
ability for a SW to add rules like "for this set of URLs, never wake
me up and instead go directly to the network".



Yeah, I suspect we may need to consider some optimizations along these
lines for other reasons too.


I have a strong preference to consider that question independently of what
we do for cross-origin service composition.


I'm fine with considering that separately. But we can certainly look
at optimizing away starting the initiating's site's SW separately.

But adding new APIs to work around lack of optimizations in existing
APIs doesn't seem like a good path forward.


The notion that a SW author will
need to be savvy to what's in another SW's caches (or, worse, the version of
their SW) without the ability to have a preamble conversation (ala
postMessage(), which is what n.c() proposes) is...disconcerting. I don't
know how that becomes useful.


I don't think anyone has proposed that there's cross website knowledge
about what's cached and what's not?


Yes, that's definitely not what I was proposing.  Let's imagine B wants 
to access an HTTP service from A (https://a.com/apis/whatnot), and they 
both have a SW.  B's SW needs to make a decision today on whether or not 
to let the request to go to the network.  At that point, B's SW is 
oblivious as to whether the request would be satisfied by A's SW if it 
chooses to let it go to the network, the same way that it's oblivious if 
it's going to be handled by some kind of an HTTP cache along the way. 
If it chooses to let the request go to the network, the proposal is to 
let the request be handled by A's SW first, and A's SW will make the 
decision on whether to let the request go to the network.  If it makes 
that choice, the request will go to the network as there is no other 
candidate SW.


> For one, it allows you to offer local services that don't map to
> HTTP. This is both blessing and curse, but I think it is likely to
> be useful at the limit; e.g., reducing serialization overhead via
> transferrables.

On using services that do not map to HTTP, I'm not sure I understand why 
that is a goal.  If the real goal is to have a side channel to talk to 
the SW without having a corresponding HTTP API, that is possible with my 
proposal if A's SW declares that it can handle the 
"/apis/sw-specific-backchannel" scope, for example (in that case letting 
that request hit the network will result in a 404 as that API scope 
doesn't exist on A's server.)


Reducing serialization overhead is indeed interesting, but I think 
that's something better addressed in Fetch, so that we can reap the 
benefits both in normal fetches and in my proposal.

___
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

[Ehsan Akhgari]

On 2014-12-11 11:12 AM, David Rajchenbach-Teller wrote:

Isn't that the same issue as Web Activities/Web Intents?


Not really.  The use cases around web activities/intents are mostly 
around user facing interactions (for example, opening a file in a web 
application, or using a web application to send an email/message) 
whereas the current proposal is about a client-side programmatic 
interface between Web applications.  The version of this use case with 
the assistance of a server has been around on the Web for a long time 
(see the various RESTful APIs published by various web services these 
days.)  The current service worker spec allows for simple caching of the 
results of those API calls without the ability of doing anything 
smarter.  The current discussion is about full blown communication 
between SWs for various websites which will allow them to actually 
synthesize a response.


Cheers,
Ehsan
___
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

[Ehsan Akhgari]

On 2014-12-11 2:17 PM, Alex Russell wrote:



On Thu, Dec 11, 2014 at 11:04 AM, Ehsan Akhgari mailto:ehsan.akhg...@gmail.com>> wrote:

On 2014-12-11 2:03 AM, Jonas Sicking wrote:

On Wed, Dec 10, 2014 at 6:22 PM, Alex Russell
mailto:slightly...@google.com>> wrote:

On Wed, Dec 10, 2014 at 5:48 PM, Ehsan Akhgari
mailto:ehsan.akhg...@gmail.com>>
wrote:


On 2014-12-10 7:45 PM, Jonas Sicking wrote:


On Wed, Dec 10, 2014 at 4:22 PM, Jonas Sicking
 wrote:


On Wed, Dec 10, 2014 at 1:02 PM,
mailto:slightly...@google.com>> wrote:


2) Users could more easily write
infinite loops between SWs, since at
no point would they be guaranteed to
bottom out at the network.



I'm more worried about the memory
implications for low-spec devices of
the russian-doll design for SW fetches.
We've avoided it thus far for these
reasons.



How does navigator.connect() address this problem?

In Ehsan's proposal SW from site A would do a
fetch() which starts the
SW from site B. In the navigator.connect()
proposal the SW from site A
would do a navigator.connect() which starts the
SW from site B.

So the same number of SWs seem to be started,
the only difference is
the API that's used to start them, no?



Hmm.. actually navigator.connect() does actually
partially address this
problem.

It allows site A to talk to site B without using
fetch() at all. Thus
enabling A to avoid using the A SW at all.

Though that particular goal could be reached by
adding some of the
optimizations that we talked about early on in SWs
design. I.e. the
ability for a SW to add rules like "for this set of
URLs, never wake
me up and instead go directly to the network".



Yeah, I suspect we may need to consider some
optimizations along these
lines for other reasons too.


I have a strong preference to consider that question
independently of what
we do for cross-origin service composition.


I'm fine with considering that separately. But we can certainly look
at optimizing away starting the initiating's site's SW separately.

But adding new APIs to work around lack of optimizations in existing
APIs doesn't seem like a good path forward.

The notion that a SW author will
need to be savvy to what's in another SW's caches (or,
worse, the version of
their SW) without the ability to have a preamble
conversation (ala
postMessage(), which is what n.c() proposes)
is...disconcerting. I don't
know how that becomes useful.


I don't think anyone has proposed that there's cross website
knowledge
about what's cached and what's not?


Yes, that's definitely not what I was proposing.  Let's imagine B
wants to access an HTTP service from A (https://a.com/apis/whatnot),
and they both have a SW.  B's SW needs to make a decision today on
whether or not to let the request to go to the network.  At that
point, B's SW is oblivious as to whether the request would be
satisfied by A's SW if it chooses to let it go to the network, the
same way that it's oblivious if it's going to be handled by some
kind of an HTTP cache along the way. If it chooses to let the
request go to the network, the proposal is to let the request be
handled by A's SW first, and A's SW will make the decision on
whether to let the request go to the network.  If it makes that
choice, the request will go to the network as there is no other
candidate SW.


The composition of SW's for fetch is an interesting problem, but I'm
entirely unconvinced that it's important. For static resources, B's SW
can cache resources from A.com and, without any extra SW spin-up, know
what resources it has.



Hmm, I wasn't talking about static resources at all.  I think the 
current SW spec gives us everything we need for same and cross origin 
static resources.



For the purposes of API composition, either this (or
navigator.connect()) will 

Re: Cross origin communication and the navigator.connect API

[Anne van Kesteren]

On Wed, Dec 10, 2014 at 6:46 PM, Ehsan Akhgari  wrote:
> So I guess my biggest question so far is: what will we gain by adding
> another API specifically for connecting to the service worker?  Do you think
> we can avoid doing that and focus on making XHR/fetch work with cross origin
> SWs?

One idea that has been making the rounds in service worker issues is
having a message channel associated with a request. So when e.g. 
does a fetch, we could expose its request as a Request object to the
page. But furthermore, we could also offer a way on that object to
communicate with the service worker's event that is handling the
request, which would allow for adjusting the priority and such, but
could also be seen as a low-level explanation of how responses get
back to the page.

Given that, both API styles discussed here, messaging and fetching,
make some sense to me. I'm not sure we necessarily need to be
exclusive. The latter is nice in that it integrates well with existing
HTTP APIs, the former is nice in that it has a lot more flexibility as
you don't need to follow request/response.


-- 
https://annevankesteren.nl/
___
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

[David Rajchenbach-Teller]

Ok, that makes sense.

I like your proposal.

Cheers,
 David

On 11/12/14 20:09, Ehsan Akhgari wrote:
> Not really.  The use cases around web activities/intents are mostly
> around user facing interactions (for example, opening a file in a web
> application, or using a web application to send an email/message)
> whereas the current proposal is about a client-side programmatic
> interface between Web applications.  The version of this use case with
> the assistance of a server has been around on the Web for a long time
> (see the various RESTful APIs published by various web services these
> days.)  The current service worker spec allows for simple caching of the
> results of those API calls without the ability of doing anything
> smarter.  The current discussion is about full blown communication
> between SWs for various websites which will allow them to actually
> synthesize a response.
> 
> Cheers,
> Ehsan


-- 
David Rajchenbach-Teller, PhD
 Performance Team, Mozilla



signature.asc
Description: OpenPGP digital signature
___
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

[Jonas Sicking]

On Thu, Dec 11, 2014 at 11:17 AM, Alex Russell  wrote:
> For the purposes of API composition, either this (or navigator.connect())
> will do.

One thing that we'll need to solve in a lot of the scenarios discussed
in this thread, including navigator.connect(), cross origin SW fetch()
and WebActivities/WebIntents are how to communicate with the SW from a
different origin when the SW from that origin might not be installed
yet.

One solution would be to at that point allow the SW from the other
origin to install itself, which means that you can then just talk to
it as a normal installed SW. However installing a SW could take
significant amount of time. On the order of tens of seconds if the
user is on a slow connection and the SW represent an app with heavy
resources.

So we might need to enable SWs to handle events without first being
installed. Or maybe while they are being installed.

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

Intent to Implement: User Timing API

[Kyle Machulis]

Summary: We've already got the performance resource timing API implemented 
(https://bugzilla.mozilla.org/show_bug.cgi?id=822480), but never got around to 
implementing the user timing API. This would allow users to set unique marks 
for profiling events in their own code, and most of the objects already exist, 
we just need to expose/store them in the right way. There's some performance 
tools being developed for FxOS that polyfill this API, but it'd be nice to just 
have it done. 

Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=782751 

Link to Standard: http://www.w3.org/TR/user-timing/ 

Platform Coverage: all 

Estimated or Target Release: Firefox 38 

Preference behind which this will be implemented: dom.enable_performance 
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to Implement: User Timing API

[Jonas Sicking]

Yes!

On Thu, Dec 11, 2014 at 5:11 PM, Kyle Machulis  wrote:
> Summary: We've already got the performance resource timing API implemented 
> (https://bugzilla.mozilla.org/show_bug.cgi?id=822480), but never got around 
> to implementing the user timing API. This would allow users to set unique 
> marks for profiling events in their own code, and most of the objects already 
> exist, we just need to expose/store them in the right way. There's some 
> performance tools being developed for FxOS that polyfill this API, but it'd 
> be nice to just have it done.
>
> Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=782751
>
> Link to Standard: http://www.w3.org/TR/user-timing/
>
> Platform Coverage: all
>
> Estimated or Target Release: Firefox 38
>
> Preference behind which this will be implemented: dom.enable_performance
> ___
> 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: Intent to Implement: User Timing API

[Kyle Machulis]

Small correction, the preference should be dom.enable_user_timing, not 
dom.enable_performance 

- Original Message -

> From: "Jonas Sicking" 
> To: "Kyle Machulis" 
> Cc: "dev-platform" , "dev-webapi"
> 
> Sent: Thursday, December 11, 2014 5:15:22 PM
> Subject: Re: Intent to Implement: User Timing API

> Yes!

> On Thu, Dec 11, 2014 at 5:11 PM, Kyle Machulis  wrote:
> > Summary: We've already got the performance resource timing API implemented
> > (https://bugzilla.mozilla.org/show_bug.cgi?id=822480), but never got
> > around to implementing the user timing API. This would allow users to set
> > unique marks for profiling events in their own code, and most of the
> > objects already exist, we just need to expose/store them in the right way.
> > There's some performance tools being developed for FxOS that polyfill this
> > API, but it'd be nice to just have it done.
> >
> > Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=782751
> >
> > Link to Standard: http://www.w3.org/TR/user-timing/
> >
> > Platform Coverage: all
> >
> > Estimated or Target Release: Firefox 38
> >
> > Preference behind which this will be implemented: dom.enable_performance
> > ___
> > 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: Intent to Implement: User Timing API

[Kan-Ru Chen]

Yes! The marks could be used by SPS or Tasktracer!

Kyle Machulis  writes:

> Small correction, the preference should be dom.enable_user_timing, not 
> dom.enable_performance 
>
> - Original Message -
>
>> From: "Jonas Sicking" 
>> To: "Kyle Machulis" 
>> Cc: "dev-platform" , "dev-webapi"
>> 
>> Sent: Thursday, December 11, 2014 5:15:22 PM
>> Subject: Re: Intent to Implement: User Timing API
>
>> Yes!
>
>> On Thu, Dec 11, 2014 at 5:11 PM, Kyle Machulis  wrote:
>> > Summary: We've already got the performance resource timing API implemented
>> > (https://bugzilla.mozilla.org/show_bug.cgi?id=822480), but never got
>> > around to implementing the user timing API. This would allow users to set
>> > unique marks for profiling events in their own code, and most of the
>> > objects already exist, we just need to expose/store them in the right way.
>> > There's some performance tools being developed for FxOS that polyfill this
>> > API, but it'd be nice to just have it done.
>> >
>> > Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=782751
>> >
>> > Link to Standard: http://www.w3.org/TR/user-timing/
>> >
>> > Platform Coverage: all
>> >
>> > Estimated or Target Release: Firefox 38
>> >
>> > Preference behind which this will be implemented: dom.enable_performance
>> > ___
>> > dev-platform mailing list
>> > dev-platform@lists.mozilla.org
>> > https://lists.mozilla.org/listinfo/dev-platform
> ___
> dev-webapi mailing list
> dev-web...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-webapi
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to Implement: User Timing API

[Ehsan Akhgari]

Nice!

Eli was looking into this recently as well, not sure if you guys have 
talked about this, if not, you should.  :-)


On 2014-12-11 8:11 PM, Kyle Machulis wrote:

Summary: We've already got the performance resource timing API implemented 
(https://bugzilla.mozilla.org/show_bug.cgi?id=822480), but never got around to 
implementing the user timing API. This would allow users to set unique marks 
for profiling events in their own code, and most of the objects already exist, 
we just need to expose/store them in the right way. There's some performance 
tools being developed for FxOS that polyfill this API, but it'd be nice to just 
have it done.

Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=782751

Link to Standard: http://www.w3.org/TR/user-timing/

Platform Coverage: all

Estimated or Target Release: Firefox 38

Preference behind which this will be implemented: dom.enable_performance
___
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: Cross origin communication and the navigator.connect API

[Jonas Sicking]

On Thu, Dec 11, 2014 at 5:56 PM, Alex Russell  wrote:
>> One solution would be to at that point allow the SW from the other
>> origin to install itself, which means that you can then just talk to
>> it as a normal installed SW. However installing a SW could take
>> significant amount of time. On the order of tens of seconds if the
>> user is on a slow connection and the SW represent an app with heavy
>> resources.
>
> I'm OK with it taking time. The discovery phase of a n.c() setup is async.

This is along time though. If the initiating website is holding *any*
UX before getting a response you'll end up with a unreasonably bad
experience. So for example if cross-site communication is initiated
when the user press a button, the response to that button push can
take unacceptably long.

It also means that we couldn't use SW for WebActivities/WebIntents for
example. That seems unfortunate.

I don't feel like we're heading down the right design.

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

Re: Intent to Implement: User Timing API

[Kyle Machulis]

Yup, this is all Eli's fault. :) 

- Original Message -

> From: "Ehsan Akhgari" 
> To: "Kyle Machulis" , dev-platform@lists.mozilla.org,
> dev-web...@lists.mozilla.org, "Eli Perelman" 
> Sent: Thursday, December 11, 2014 5:57:44 PM
> Subject: Re: Intent to Implement: User Timing API

> Nice!

> Eli was looking into this recently as well, not sure if you guys have
> talked about this, if not, you should. :-)

> On 2014-12-11 8:11 PM, Kyle Machulis wrote:
> > Summary: We've already got the performance resource timing API implemented
> > (https://bugzilla.mozilla.org/show_bug.cgi?id=822480), but never got
> > around to implementing the user timing API. This would allow users to set
> > unique marks for profiling events in their own code, and most of the
> > objects already exist, we just need to expose/store them in the right way.
> > There's some performance tools being developed for FxOS that polyfill this
> > API, but it'd be nice to just have it done.
> >
> > Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=782751
> >
> > Link to Standard: http://www.w3.org/TR/user-timing/
> >
> > Platform Coverage: all
> >
> > Estimated or Target Release: Firefox 38
> >
> > Preference behind which this will be implemented: dom.enable_performance
> > ___
> > 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

PSA: xpcshell tests can now be debugged using devtools

[Mark Hammond]

Just an hour or so ago, support landed on mozilla-central which gives us 
the ability to use the devtools debugger to debug xpcshell tests \o/


To use this, simply add "--jsdebugger" to the xpcshell/mach command-line 
- eg:


  ./mach xpcshell-test --jsdebugger path/to/a/test.js

then wait for the xpcshell process to start and to output a message 
indicating it is waiting for the debugger.  Then from a (nightly, 
non-e10s - see below) Firefox instance, use devtools->connect to connect 
to the xpcshell process.  WebIDE should also work.


Caveats:
* You can only use this to debug a single test, so specifying (eg) a 
directory of tests isn't going to work (you'll get an error starting the 
xpcshell process)


* Unrelated to this change, the devtools code recently changed such that 
earlier devtools clients can't debug newer servers - see bug 905700 and 
bug 1105493 - there's some talk of uplifting, but for now you need to 
use a Nightly Firefox to connect to the xpcshell tests.  Also, last I 
checked things didn't work with e10s - so you need a Nightly with e10s 
disabled.


* There remain a few paper-cuts (eg, the "console" might not fully work) 
but in general, the debugger itself works fine.


Thanks to :gps for getting this ball rolling many months ago, and 
particularly to :past who patiently helped with the devtools magic that 
was necessary to get this working.


Spread the word!

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

Proposed W3C Charter: Web of Things Interest Group

[L. David Baron]

The W3C is proposing a revised charter for:

  Web of Things Interest Group
  http://www.w3.org/2014/09/wot-ig-charter.html
  http://lists.w3.org/Archives/Public/public-new-work/2014Nov/.html

Mozilla has the opportunity to send comments or objections through
next Monday, December 15.

Please reply to this thread if you think there's something we should
say as part of this charter review, or whether you think we should
explicitly abstain.

-David

-- 
𝄞   L. David Baron http://dbaron.org/   𝄂
𝄢   Mozilla  https://www.mozilla.org/   𝄂
 Before I built a wall I'd ask to know
 What I was walling in or walling out,
 And to whom I was like to give offense.
   - Robert Frost, Mending Wall (1914)


signature.asc
Description: Digital signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform