905263 - Implement a blackbox pragma

Status: NEW

(DevTools :: Debugger, enhancement, P3)

Description

[Nick Fitzgerald [:fitzgen] [⏰PST; UTC-8]]

Then the source would be black boxed by default. This would allow jquery/ember/angular/any js lib to say that it thinks it should be black boxed by default.

Comment 1

[Yehuda Katz]

I think that makes sense.

Some thoughts:
* `//@blackbox=ember`: this would make a list of the blackbox names in the UI and they could be toggled based on the specified names. This would also allow a single checkbox if a library is spread across several files.
* `X-Debug-Blackbox: ember`: same as above, but would allow a server to specify that a JS file was blackboxable.
* A source map extension that would allow specific bindings to be blackboxed.

Comment 2

[Nick Fitzgerald [:fitzgen] [⏰PST; UTC-8]]

(In reply to Yehuda Katz from comment #1)
> I think that makes sense.
> 
> Some thoughts:
> * `//@blackbox=ember`: this would make a list of the blackbox names in the
> UI and they could be toggled based on the specified names. This would also
> allow a single checkbox if a library is spread across several files.

So rather than saying that the source should be black boxed by default, this would say which library this source belongs to so we could black box whole groups of sources that belong to a single library at once?

Or it says both of these things?

Note that we should use //# instead of //@ because of the problems with IE conditional compilatation that plagued the sourceMappingURL pragma.

> * `X-Debug-Blackbox: ember`: same as above, but would allow a server to
> specify that a JS file was blackboxable.

+1

Filed bug 905859

> * A source map extension that would allow specific bindings to be blackboxed.

Would be fairly easy to add something like

{
  sources: ["foo.js", "bar.js", "blackboxed.js"],
  xBlackBoxedSources: [2],
  // rest of the source map
}

where the values of `xBlackBoxedSources` are ordered indices into the `sources` list. We could do a similar extension to the format for individual mappings.

Filed bug 905863

Comment 3

[Yehuda Katz]

> So rather than saying that the source should be black boxed by default, this would say which library this source belongs to so we could black box whole groups of sources that belong to a single library at once?
>
> Or it says both of these things?

I think both.

Comment 4

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

(In reply to Yehuda Katz from comment #1)
> * `X-Debug-Blackbox: ember`: same as above, but would allow a server to
> specify that a JS file was blackboxable.

Hrm, what's the value of letting servers provide blackbox info?  Adding //# pragmas to files is simple enough, and presumably we can get frameworks to just ship with them.  Doing the http header seems like just an interim step until frameworks add in the pragma, but I suspect that it will cause mild headaches later.. for example, what happens if a server rule makes it send "X-Debug-Blackbox: framework" for everything in /framework/, but /framework/ember.js is present that says "//#blackbox=ember"?  Does it show up as "framework" or "ember"?  Either one is potentially unexpected.

Comment 5

[Yehuda Katz]

(In reply to Vladimir Vukicevic [:vlad] [:vladv] from comment #4)
> (In reply to Yehuda Katz from comment #1)
> > * `X-Debug-Blackbox: ember`: same as above, but would allow a server to
> > specify that a JS file was blackboxable.
> 
> Hrm, what's the value of letting servers provide blackbox info?  Adding //#
> pragmas to files is simple enough, and presumably we can get frameworks to
> just ship with them.  Doing the http header seems like just an interim step
> until frameworks add in the pragma, but I suspect that it will cause mild
> headaches later.. for example, what happens if a server rule makes it send
> "X-Debug-Blackbox: framework" for everything in /framework/, but
> /framework/ember.js is present that says "//#blackbox=ember"?  Does it show
> up as "framework" or "ember"?  Either one is potentially unexpected.

I can buy that.

Comment 6

[Eddy Bruel [:ejpbruel]]

I think this should be the approach we take, instead of blackboxing common libraries by default (903217) or implementing a blackbox HTTP header (905859)

Comment 7

[Alex Vincent [:WeirdAl]]

How would this work for XPCOMUtils.jsm?  That file needs blackboxing regularly.

Comment 8

[Nick Fitzgerald [:fitzgen] [⏰PST; UTC-8]]

(In reply to Alex Vincent [:WeirdAl] from comment #7)
> How would this work for XPCOMUtils.jsm?  That file needs blackboxing
> regularly.

Once implemented, you would add something like `//# blackbox=firefox` to the bottom of the file.