I have encountered a similar problem with JS injection.  There are HTTP proxy servers that inject JavaScript into HTML and JS documents ... I believe the purpose of the injected snippets is to examine the DOM and/or the JS code to try and squelch malicious behavior.<p>The problem is that this particular proxy observes the MIME type in the content-type header very strictly when deciding to inject raw JS or JS bounded by HTML "script" and "/script" tags.<p>I've found that a number of sites return a content-type of "text/html" for pure JS documents ... documents often referred to in HTML documents via "script src=xxx".  The appliance then injects the HTML "script" tags into the raw JS document, breaking the legal JS code.<p>This causes the JS runtime to halt processing for a number of sites.  For many, the sites become unusable as event-handlers are either not in place or refer to functions that did not have a chance to solidify.  Some don't render correctly.<p>I built a pair of documents illustrating the problem and showed the proxy vendor the difference in behavior when the JS document had a MIME type of "text/javascript" as opposed to "text/html".  They told me that their proxy is behaving correctly and that the sites are broken as they are returning incorrect content-type headers.<p>Their advice was to contact the offending site when I encountered such a problem and ask them to correct the issue.<p>I should note that this proxy server does have a programming interface.  It is possible to alter the behavior of the proxy via this interface to more intelligently inspect documents with "text/html" to determine if they contain HTML markup.  My concern was that while I could fix it for my use of the proxy, other users out in the wild would be subject to the same problem.<p>I'm not a fan of this trend of script-injection, even under the guise of making computing safe for the end-user.  I've begun to wonder if it's time to include self-checks in JavaScript code to ensure that no alteration has occurred in transit.