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

[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
<https://tools.ietf.org/html/rfc3864#section-4>)?

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

-Boris

[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.

> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>

[Tom Tromey]

>>>>> "Boris" == Boris Zbarsky <bzba...@mit.edu> 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> <https://tools.ietf.org/html/rfc3864#section-4>)?

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

[Nick Fitzgerald]

On Wed, May 17, 2017 at 10:51 AM, Tom Tromey <ttr...@mozilla.com> wrote:

> >>>>> "Boris" == Boris Zbarsky <bzba...@mit.edu> 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

[Anne van Kesteren]

On Wed, May 17, 2017 at 8:14 PM, Nick Fitzgerald
<nfitz...@mozilla.com> 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/

[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

[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)

[Tom Tromey]

>>>>> "David" == L David Baron <dba...@dbaron.org> 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.

Tom

[L. David Baron]

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)

[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.de...@googlegroups.com [mailto:mozilla.de...@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.)

[Domenic Denicola]

From: mozilla.de...@googlegroups.com [mailto:mozilla.de...@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

[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 <d...@domenic.me> wrote:

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

> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>

--
----
Liz Henry (:lizzard)
Firefox Release Manager
lhe...@mozilla.com