Add crossorigin support for cross-domain script debugging

[MassiveMedia]

When you want to load a crossorigin javascript, adding the crossorigin attribute provides the ability to have more information in the onError handler.
See: https://developer.mozilla.org/en-US/docs/HTML/Element/script#attr-crossorigin

[getify]

Another point we'd probably want to consider is to feature-test for the feature, and only set on the script tag if supported. Reason being: it the attribute is added to a script element where the feature is not itself supported, that could be misleading when trying to debug LABjs behavior.

[soxofaan]

Hi,

http://blog.errorception.com/2012/12/catching-cross-domain-js-errors.html gives some more real-world background about this feature request.

if we add this to core, this should only be in the debug build of LABjs and not the main minified build,

I disagree here, we want to use this feature for error logging on our live production site, for catching errors in the browser from our real users (where we have a setup with CDN and cross origin issues). It is not for debugging (when you typically don't work with a CDN and don't have cross origin issues).

[getify]

if we add this to core, this should only be in the debug build of LABjs and not the main minified build,

I disagree here, we want to use this feature for error logging on our live production site, for catching errors in the browser from our real users (where we have a setup with CDN and cross origin issues). It is not for debugging (when you typically don't work with a CDN and don't have cross origin issues).

I have regularly over the years recommended to users of LABjs that they take the debug build of LABjs (which is a little bit bigger, and runs a few extra bits of logic at each step) and deploy it into their production site, so they can debug issues that seem to only be reproducible in their prod environment.

But note, this sort of action is still fundamentally a debugging step, and should be considered, IMO, a temporary step while you diagnose and fix issues. It should not be a permanent installation in a prod environment. For example, debug mode by default logs all the steps LABjs takes to the console, but that sort of logging is extraneous for a production environment, and moreover, could be considered a "leak" of implementation you would probably be best served avoiding for prod.

All the debug features of LABjs are specifically for the purpose of debugging issues and correcting them. That means all of those features should be temporary, not permanent, in prod. As such, I have a hard time believing we've come up with a new fundamentally "debugging" feature for LABjs that would be constantly running (and deployed) on a permanent basis in production. That sorta violates one of my fundamental principles of good software design.

CAN you do that? Of course. It's not something I'd ever recommend. LABjs is not really designed to be a tool in the RUM toolbox, it's not for continuous monitoring or stats/error gathering, etc. If I were to design that sort of software, I'd probably approach it quite differently than how I built LABjs. By contrast, LABjs is as simple and stripped down and bare metal as it possibly can be, because it has one task and one task only: loading scripts. Any of its capabilities to track or provide assistance in debugging are intended for debugging purposes only.

This is a similar discussion (and mindset) to me as issue #57 where there was quite a bit of back-n-forth discussion about my design philosophy of defaulting to having the wait() method suppress errors by default, and only expose them when you choose to move into Debug:true mode (and of course, using the debug build of the lib). Several people in that thread definitely disagreed with that being the default behavior, but I considered that to be the more appropriate conservative default for simple production environments, while giving the power and flexibility to someone to use a different build/mode if they need to dig into an issue.

My mindset then, and now, is that LABjs is best served by being as stripped down, and conservative, as possible in the core minified build, and debug functionality is tucked away in the debug build, easily useable if necessary to track down and fix problems. Hopefully that helps elaborate on how I might tend to approach this feature request, if we do add it.

[alexstanbury]

Did this ever make it into the debug build? I can't see anything in the docs or from a quick scan of the code.

[Enalmada]

I don't believe it is safe for any website supporting service workers to use LABjs in production without crossorigin functionality. I have just learned the hard way that a service worker can't see the response code of scripts loaded from external cdn unless crossorigin="anonymous" is added:
<script src="https://cdn.example.com/foo.js" crossorigin="anonymous">

Without crossorigin, the service worker just sees result status 0 "opaque" for everything and if there happens to be an error, it will cache the error response in the client browser till cache timeout (which people usually set very long since these are static assets).

I came here in hopes that there was a flag to enable LABjs crossorigin and found this pull request. Because the landscape has changed since this pull request was opened and service workers are a thing now, I am hoping that it makes for crossorigin to be officially supported.

[getify]

I'm definitely of a different mindset on this than when it was originally filed. I'm now inclined to support setting any attribute on the script element that you want, as discussed in #108. That work would roll into LABjs v3, though, not an update of 2.x.

I made some decent progress on the 3.0 rewrite (#113) awhile back, but there's a long check list of stuff still to do. I would love any help with that list. :)

In the meantime, I guess my best suggestion is to edit your LABjs to add the attribute. I believe that would be inserted here: https://github.com/getify/LABjs/blob/master/LAB.src.js#L132

[Enalmada]

That insert suggestion is perfect! Thank you @getify (and @MassiveMedia) for keeping me going with LABjs until 3.0 is ready. I love it very much and am very grateful for such a fantastic contribution to the community.