Re: Intent to ship: SourceMap header

[Liz Henry (:lizzard)]

Is there any objection to landing the patch from
https://bugzilla.mozilla.org/show_bug.cgi?id=1346936 and shipping it in 55
as it stands now?

I read this thread and can see there is a lot that could and maybe should
be done with writing a spec and engaging with standards orgs.  But, does
that block us shipping? Do we have enough test coverage and so on?

And, any feedback here from the JS team?


Best,

Liz


On Fri, May 26, 2017 at 11:53 AM, Domenic Denicola  wrote:

> (Re-sending as I was informed that "posting by email is not allowed";
> apologies to those who get this email twice.)
>
> From: mozilla.dev.platf...@googlegroups.com [mailto:mozilla.dev.platform@
> googlegroups.com] On Behalf Of L. David Baron
> >
> > On Friday 2017-05-26 11:53 -0600, Tom Tromey wrote:
> >> How would I go about starting this?
> >> I have never done anything with web standards before.
> >
> > Probably something like:
> >
> >  (1) ask the current maintainers of the spec if they're ok with you
> doing this
>
> This speaks to the larger issue here, which is finding someone who is
> willing to devote ongoing effort to maintaining the spec. It's a serious
> long-term commitment, not just something to check off the box before
> shipping a new feature. My understanding is there are current maintainers
> who are happy with their workflow using a Google doc. If you want to move
> to a new technology, you need to get them to come along and help with the
> conversion process, and you need to stick around as part of the team
> committed to maintaining the spec long-term, driving consensus on new
> features.
>
> https://whatwg.org/working-mode may give you somewhat of an idea of how
> the ongoing process of maintaining a spec works. It is for a different
> standards organization than the one dbaron suggests, but the general
> framework remains.
>
> (BTW, if the spec ends up successful in the WICG, we can talk about
> migrating it from incubation in the WICG to a full-fleged WHATWG
> specification, as was suggested by some people up-thread. But it would be
> good to see ongoing positive signs of engagement first with the proposed
> new spec.)
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>



-- 

Liz Henry (:lizzard)
Firefox Release Manager
lhe...@mozilla.com
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

RE: Intent to ship: SourceMap header

[Domenic Denicola]

From: mozilla.dev.platf...@googlegroups.com 
[mailto:mozilla.dev.platf...@googlegroups.com] On Behalf Of L. David Baron
>
> On Friday 2017-05-26 11:53 -0600, Tom Tromey wrote:
>> How would I go about starting this?
>> I have never done anything with web standards before.
>
> Probably something like:
>
>  (1) ask the current maintainers of the spec if they're ok with you  doing 
> this

This speaks to the larger issue here, which is finding someone who is willing 
to devote ongoing effort to maintaining the spec. It's a serious long-term 
commitment, not just something to check off the box before shipping a new 
feature. My understanding is there are current maintainers who are happy with 
their workflow using a Google doc. If you want to move to a new technology, you 
need to get them to come along and help with the conversion process, and you 
need to stick around as part of the team committed to maintaining the spec 
long-term, driving consensus on new features.

https://whatwg.org/working-mode may give you somewhat of an idea of how the 
ongoing process of maintaining a spec works. It is for a different standards 
organization than the one dbaron suggests, but the general framework remains.

(BTW, if the spec ends up successful in the WICG, we can talk about migrating 
it from incubation in the WICG to a full-fleged WHATWG specification, as was 
suggested by some people up-thread. But it would be good to see ongoing 
positive signs of engagement first with the proposed new spec.)
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: SourceMap header

[Domenic Denicola]

(Re-sending as I was informed that "posting by email is not allowed"; apologies 
to those who get this email twice.)

From: mozilla.dev.platf...@googlegroups.com 
[mailto:mozilla.dev.platf...@googlegroups.com] On Behalf Of L. David Baron
>
> On Friday 2017-05-26 11:53 -0600, Tom Tromey wrote:
>> How would I go about starting this?
>> I have never done anything with web standards before.
>
> Probably something like:
>
>  (1) ask the current maintainers of the spec if they're ok with you  doing 
> this

This speaks to the larger issue here, which is finding someone who is willing 
to devote ongoing effort to maintaining the spec. It's a serious long-term 
commitment, not just something to check off the box before shipping a new 
feature. My understanding is there are current maintainers who are happy with 
their workflow using a Google doc. If you want to move to a new technology, you 
need to get them to come along and help with the conversion process, and you 
need to stick around as part of the team committed to maintaining the spec 
long-term, driving consensus on new features.

https://whatwg.org/working-mode may give you somewhat of an idea of how the 
ongoing process of maintaining a spec works. It is for a different standards 
organization than the one dbaron suggests, but the general framework remains.

(BTW, if the spec ends up successful in the WICG, we can talk about migrating 
it from incubation in the WICG to a full-fleged WHATWG specification, as was 
suggested by some people up-thread. But it would be good to see ongoing 
positive signs of engagement first with the proposed new spec.)
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: SourceMap header

[L. David Baron]

On Friday 2017-05-26 11:53 -0600, Tom Tromey wrote:
> > "David" == L David Baron  writes:
> 
> David> I agree it would be good to have a somewhat more "proper" spec for
> David> this.  In terms of process,  I think probably the most important
> David> (and lowest overhead) aspect of "proper" is having the revision
> David> history of the specification in publicly visible version control
> David> (such as github), and a way for people to raise issues that will be
> David> looked at.
> 
> How would I go about starting this?
> I have never done anything with web standards before.

Probably something like:

 (1) ask the current maintainers of the spec if they're ok with you
 doing this

 (2) [optional, though perhaps preferable] join the WICG, as
 described in https://github.com/WICG/admin/

 (3) in a github repository (either yours or one in the WICG space),
 convert the document to something specs tend to be written in
 (https://github.com/tabatkins/bikeshed/ is probably preferable,
 although there are other options), possibly preserving the existing
 history of the specification in some format (which given that it's
 currently a google doc, probably wouldn't be the bikeshed format).
 There are various tricks for doing things like setting up
 autopublication to gh-pages using bikeshed, e.g., as documented in
 https://gist.github.com/domenic/ec8b0fc8ab45f39403dd with an
 example you can see in a repo like
 https://github.com/w3ctag/design-principles )

 (4) continue iterating on the specification in that repository
 (source code and issues)

-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: PGP signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: SourceMap header

[L. David Baron]

On Wednesday 2017-05-17 11:14 -0700, Nick Fitzgerald wrote:
> If the effort re-materializes, here's what I think should be focused on:
> 
> * Clean up the spec text and any ambiguities it may have; make it a
> "proper" standard

I agree it would be good to have a somewhat more "proper" spec for
this.  In terms of process,  I think probably the most important
(and lowest overhead) aspect of "proper" is having the revision
history of the specification in publicly visible version control
(such as github), and a way for people to raise issues that will be
looked at.

-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: PGP signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: SourceMap header

[Boris Zbarsky]

On 5/17/17 2:14 PM, Nick Fitzgerald wrote:

In my experience, trying to get anyone to comment or provide feedback on
source map RFCs was a huge pain, and it felt to me like nobody (other
browser devtools teams, maintainers of compilers targeting JS) cared enough
about source maps to get involved or contribute.


OK, but can we at least make sure the browser devtools teams and 
compilers targeting JS are all on the same page with respect to this 
stuff?  Do we know whether they are or not?  This was not indicated in 
the initial intent in any way.



* Clean up the spec text and any ambiguities it may have; make it a
"proper" standard


I think this would be a good thing to do anyway.  Otherwise we're likely 
to end up needing to reverse-engineer other browsers around this stuff.


Specifically, we should have a spec for the sourcemap header, and 
separately we should have a spec for the sourcemap itself.


And we should actually register the header.


* Pull a wasm on the source map format: create an isomorphic, but much more
compact binary format
* Add the ability to encode source level scopes, bindings, and a way to
recover bindings' values


Those sound good, as part of the spec work...

-Boris

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

Re: Intent to ship: SourceMap header

[Anne van Kesteren]

On Wed, May 17, 2017 at 8:14 PM, Nick Fitzgerald
 wrote:
> At the time of the thread, I had hopes that the source map RFC repo would
> take off. It never did. Maybe making a "proper" WHATWG standard would help
> get people involved, in which case it would be a good idea. I wasn't trying
> to push back in that thread, just making sure that we had good answers to
> those questions because if we didn't then why do it in the first place.

Perhaps https://console.spec.whatwg.org/ is a good fit? Although that
mostly deals with web-exposed behavior at this point.


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

Re: Intent to ship: SourceMap header

[Nick Fitzgerald]

On Wed, May 17, 2017 at 10:51 AM, Tom Tromey  wrote:

> > "Boris" == Boris Zbarsky  writes:
>
> >> https://github.com/source-map/source-map-rfc
>
> Boris> Are there any plans to have a standard here?
>
> All I found was this:
> https://groups.google.com/forum/#!topic/mozilla.dev.js-
> sourcemap/SD8sZ_7VFpw
>
> ... my reading of that was that there wasn't interest on our part at the
> time.  I suppose we could reopen that.
>

​At the time of the thread, I had hopes that the source map RFC repo would
take off. It never did. Maybe making a "proper"​ WHATWG standard would help
get people involved, in which case it would be a good idea. I wasn't trying
to push back in that thread, just making sure that we had good answers to
those questions because if we didn't then why do it in the first place.

In my experience, trying to get anyone to comment or provide feedback on
source map RFCs was a huge pain, and it felt to me like nobody (other
browser devtools teams, maintainers of compilers targeting JS) cared enough
about source maps to get involved or contribute.

If the effort re-materializes, here's what I think should be focused on:

* Clean up the spec text and any ambiguities it may have; make it a
"proper" standard
* Pull a wasm on the source map format: create an isomorphic, but much more
compact binary format
* Add the ability to encode source level scopes, bindings, and a way to
recover bindings' values
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: SourceMap header

[Tom Tromey]

> "Boris" == Boris Zbarsky  writes:

>> https://github.com/source-map/source-map-rfc

Boris> Are there any plans to have a standard here?

All I found was this:
https://groups.google.com/forum/#!topic/mozilla.dev.js-sourcemap/SD8sZ_7VFpw

... my reading of that was that there wasn't interest on our part at the
time.  I suppose we could reopen that.

Boris> It really would be good
Boris> to have all UAs converge on a single format here, both for the header
Boris> and for the sourcemap itself, especially if we're going to have an
Boris> unprefixed name for the header...  Speaking of which, is there a plan
Boris> to register this header with IANA (see
Boris> )?

I believe there is a single format for the header and the sourcemap
itself; it's just that the spec is that Google doc and the way to change
the spec is to submit a PR against the (very quiet) RFC repo on github.

I'm not aware of anybody registering the header with the IANA.  However
I've only been working in this area for a few weeks.

Boris> Is there any web-page-observable behavior change from sourcemaps
Boris> (e.g. .stack on exceptions?), or is it all about how devtools behave?

It's only observable using devtools.

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

Re: Intent to ship: SourceMap header

[Nick Fitzgerald]

Error().stack is not affected by source maps (nor should it be IMO). This
is just devtools facing with nothing that is web observable.

On Wed, May 17, 2017 at 9:06 AM, Boris Zbarsky  wrote:

> On 5/17/17 11:01 AM, Tom Tromey wrote:
>
>> In this case I think this does not apply, because as far as I'm aware
>> source maps are not part of any standard process; rather there is:
>>
>> https://github.com/source-map/source-map-rfc
>>
>
> Are there any plans to have a standard here?  It really would be good to
> have all UAs converge on a single format here, both for the header and for
> the sourcemap itself, especially if we're going to have an unprefixed name
> for the header...  Speaking of which, is there a plan to register this
> header with IANA (see )?
>
> Is there any web-page-observable behavior change from sourcemaps (e.g.
> .stack on exceptions?), or is it all about how devtools behave?
>
> -Boris
>
> ___
> 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 ship: SourceMap header

[Boris Zbarsky]

On 5/17/17 11:01 AM, Tom Tromey wrote:

In this case I think this does not apply, because as far as I'm aware
source maps are not part of any standard process; rather there is:

https://github.com/source-map/source-map-rfc


Are there any plans to have a standard here?  It really would be good to 
have all UAs converge on a single format here, both for the header and 
for the sourcemap itself, especially if we're going to have an 
unprefixed name for the header...  Speaking of which, is there a plan to 
register this header with IANA (see 
)?


Is there any web-page-observable behavior change from sourcemaps (e.g. 
.stack on exceptions?), or is it all about how devtools behave?


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

Intent to ship: SourceMap header

[Tom Tromey]

I intend to turn support for the SourceMap response header on by default
in nightly, and let it ride the trains.  It has not been developed
behind a preference.  The existing X-SourceMap header will still be used
if SourceMap is not seen; this matches the behavior of Chrome and
WebKit.

Bug to turn on by default: https://bugzilla.mozilla.org/show_bug.cgi?id=1346936

Link to standard: 
https://docs.google.com/document/d/1U1RGAehQwRypUTovF1KRlpiOFze0b-_2gc6fAH0KY0k/edit#

Testing: As far as I know there are no web-platform-tests; but we do
have mochitests for the feature.


The intent-to-ship guidelines say:

An Intent to Ship requires either a web platform test suite or such
issues to be filed explaining why such a test suite is currently
impossible or in the progress of being upstreamed.

In this case I think this does not apply, because as far as I'm aware
source maps are not part of any standard process; rather there is:

https://github.com/source-map/source-map-rfc

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