For users on very slow connections, block document.written scripts

[KenjiBaheux]

For users on high latency connections, parser-blocking scripts loaded via document.write cause significant delays in user perceived page load latency.

Most scripts inserted via document.write are for third party content. A quick survey of the third parties suggests that async solutions are commonly offered. Given how bad the user experience can get for users on slow connections, it's quite likely that a large fraction of page visits never succeeds. The hope is that these newly rescued page views would incentivize publishers to adopt async solutions.

Chrome is exploring the following intervention:

• for users on slow connections, block network requests for document.written scripts
• design doc
• crbug

[shivanigithub]

Possible Spec edits:
The "Note" in 4.12.1 mentions about scripts inserted using document.write in https://html.spec.whatwg.org/multipage/scripting.html#the-script-element:
"When inserted using the document.write() method, script elements execute (typically blocking further script execution or HTML parsing), but when inserted using innerHTML and outerHTML attributes, they do not execute at all."
We can add to this saying:
"The user agent may elect not to load synchronously loaded script elements inserted using document.write e.g. document.write('<scr' + 'ipt src="' + src + '" ></scr' + 'ipt>'). This is because such usage can cause significant delays in user perceived page load latency."

And also add similar statement in the Warning section in https://html.spec.whatwg.org/multipage/webappapis.html#document.write()

[shivanigithub]

Summarizing mail thread discussing the spec changes here:

As per feedback from ojan@ and domenic@ on the process of spec change:
"In another thread, Domenic suggested that we not add a diff to the interventions repo. Instead we can do a pull request to the HTML spec at the WHATWG and link to it from the issue in the interventions repo."

[toddreifsteck]

Per above, I've opened the linked issue on W3C HTML5 spec.

[domenic]

Per above, I've opened the linked issue on W3C HTML5 spec.

Wrong repo :). We were talking about a pull request to https://github.com/whatwg/html, which is what is implemented in browsers.

Possible Spec edits:

It's important to note include normative requirements (even "may"s) inside non-normative notes. Instead, we need to work through the normative algorithms.

Let's figure out instead how innerHTML normatively prevents script execution. It turns out it's done in the HTML parser itself. See e.g. https://html.spec.whatwg.org/multipage/syntax.html#parsing-main-inhead, where "A start tag whose tag name is "script"" step 4 says

If the parser was originally created for the HTML fragment parsing algorithm, then mark the script element as "already started". (fragment case)

(Note that "in body" delegates to "in head" for script, so this is the place to look.)

To fix this, your PR should probably just add an extra step that's very similar: something like

If the parser was invoked via the document.write() method, then optionally mark the script element as "already started". (For example, the user agent may wish to disallow third-party scripts inserted via document.write() under slow network conditions, or when page loading time is already high.)

I'm happy to write this PR if you'd prefer, although we're always happy to have more contributors to HTML. Instructions at https://github.com/whatwg/html#pull-requests

[domenic]

Oh, but of course we should also update the note you found, too! My suggestion for how to do that would be to give an id to the new <li> with that step, and then insert the word "usually" before "execute" and have the "usually" link to that <li>.

[shivanigithub]

Thanks for the feedback , Domenic.
It would be great if you write this PR. Thanks for offering.

[domenic]

OK! I wrote up the pull request at whatwg/html#1400.

[shivanigithub]

Great, thanks!

[KenjiBaheux]

Let me document the current behavior of the intervention and its associated feedback loops in Chrome.

Intervention

Chrome will block the load of document.written scripts when the following conditions are met:

Script related criteria

• Top level document. The blocking of scripts is restricted to the top level document (in other words, the intervention does not apply to document.written scripts within iframes)
• Parser-blocking. Scripts that are parser-blocking are prohibitively expensive. Note: since asynchronous scripts are not parser blocking, the intervention does not apply to these scripts.
• Cross site (i.e. hosts with different eTLD+1). To mitigate breakage of key functionality, the intervention only targets cross site scripts (i.e. scripts hosted on js.example.com will continue to work when inserted via document.write on www.example.com).
• Browser HTTP cache miss. The blocking of scripts only applies in the case of a browser HTTP cache miss. If the document.written script is already available in the browser HTTP cache, it is allowed to execute, since there is no network delay incurred in this case.

Circumstances

• Slow connections. Since the performance penalty of these scripts leads to a worst case page load experience in slow connections, we intend to block scripts only if all the above conditions are true and if the connection is slow. Initially, the change will be restricted to 2G. In the future, the change might be extended to other users on slow connections, such as slow 3G or slow WiFi.
• Not a reload. To further mitigate the possibility of breaking user functionality, Chrome will not intervene if the user triggered a reload.

Browser HTTP cache hit case

When the script needed by the document.write statement is found in the browser HTTP cache, Chrome will use it even if stale, up to a lifetime of 1 year. To mitigate version skew issues, Chrome might queue a low priority asynchronous request in order to update stale assets.

Feedback loops

In order to make the intervention actionable for developers, we will offer the following feedback loops.

Warning in devtools

Since Chrome M53, Devtools is issuing warnings for potentially problematic document.write statements. The warning is issued regardless of the connectivity.

Example:
(index):34 A Parser-blocking, cross-origin script, http://www.example.org/a.js, is invoked via document.write. This may be blocked by the browser if the device has poor network connectivity.

Intervention HTTP header (strawman)

When a script inserted via document.write has been blocked, Chrome will send:

Intervention: <https://shorturl/relevant/spec>

When a script inserted via document.write is found and could be blocked in different circumstances, Chrome might send:

Intervention: <https://shorturl/relevant/spec>; level="warning"

The intervention header will be sent as part of the GET request for the script (asynchronously in case of an actual intervention).

Updates

10/25/2016: fix incorrect usage of the term "cross origin" when we meant "cross site (i.e. hosts with different eTLD+1)".

[matthewp]

I think this is assuming that document.write() is only used for additive third party scripts like ad networks but one common use case of document.write is to fallback to a local script when a CDN fails. You can see an example of this from a very popular starter kit. This pattern has existed as far back as CDNs have been around and is probably encoded in a large number of websites.

[PaulKinlan]

In your specific scenario this intervention not trigger because your fallback script is not cross-origin.

[matthewp]

That's only true in Chrome. My concern is that giving UAs permission to do this will cause sites to behave differently in some browsers and break in some browsers.

[hexalys]

I object to blindly targeting cross-origin. It's too restrictive with potential to break some sites' core functionality. Including half a dozen of my own sites.

As I mentioned in a Tweet to @PaulKinlan I have been using cross-browser patterns such as:

document.write('<script src="/cdn/jquery/'+(!Object.defineProperty?'1.8.3' : ie<11|this.opera ? '1.11.1' : '2.2.4')+'min.js"><\/script>');

or with conditionals to load browser shims such as:

!Object.create && document.write('<script src="/cdn/lib/es5-shim.min.js"><\/script>');

As described, prohibiting cross-origin scripts from CDNs break the above use cases. In addition, given the above jQuery version method, I use jQuery fallbacks from CDNJS to Google's API. Both of them via document.write().

Some additional points:

1. This is the only way to conditionally load synchronous scripts from a CDN, for good reasons.
2. The described aim of this intervention is "reducing the impact of document.written scripts on user perceived page load latency". AFAICT that script usage early in the <head> makes no visible impact on performance.
3. Browser aren't likely able to properly evaluate such document.write(s) in the preload scanner. One of the initial motives for the crbug. And in this case, attempts in preloading those would defeat the very purpose of using them conditionally for polyfills with feature detection conditions.

I am all for preventing poorly implemented document.write "for third party content such as ads and trackers" that inject late content in the page. But we need a reasonable compromise here.

As mitigation, here an option to consider, which i'd be fine with:

Allow cross-origin scripts only when loaded in the <head>.
(easy and clear spec with no significant impact on performance).

[domenic]

Why do you believe that script usage (actually, it's document.write usage) early in the head makes no visible impact on performance? It janks the page just as bad as document.write anywhere else (it stops further parsing of the page, much less any rendering and layout, until the script is downloaded!). <head> is not a magical no-jank container.

[bzbarsky]

it stops further parsing of the page

For what it's worth, this may not be true in all UAs. It needs to stop observable DOM construction, and it needs to act as if parsing had been stopped, but you can in fact parse ahead speculatively if you want, and some UAs do that.

[ojanvafai]

The combination of DOM construction blocking and speculative parsing is actually the problem here. The speculative parsing will load resources that are needed later in the page, delaying the load of the doc.written script. On a 2G connection, by the time you doc.write the script, the network connection is already flooded loading other resources, even if it's in the head.

You can't just reprioritize the resource loads at that point because it's the upstream network bandwidth that's flooded.

We were consistently seeing page load improvements of 10-30 seconds on many pages on 2G.

@hexalys do you have a page you could point us to that doesn't see a significant improvement on a 2G connection? I'd like to understand it better. Maybe we should be doing something more nuanced.

[matthewp]

@ojanvafai A page might load quick, but load incorrectly if a needed script is ignored. If I write the entire page using jQuery and jQuery doesn't load because of this algorithm, the page is broken on such a connection.

[hexalys]

Why do you believe that script usage (actually, it's document.write usage) early in the head makes no visible impact on performance?
@domenic

By tests and observation of network waterfalls in fairly all browsers. There is little to no timing penalty for the overall document in loading jQuery via document.write(). Compare those 2 tests as examples:

Test A : Nexus 7 - Chrome - 2G speed (using document.write jQuery).
Test B : Nexus 7 - Chrome - 2G speed (using normal sync jQuery).

The only difference is a very small negligible priority penalty of 10-20ms only for the script itself.

It janks the page just as bad as document.write anywhere else (it stops further parsing of the page, much less any rendering and layout, until the script is downloaded!). is not a magical no-jank container.
@domenic

It doesn't stop rendering any more than any other synchronous script. It's not that's it's a magical no-jank container. As an aside, I just assume that having it at the top where the body is not yet parsed has a more minimal impact with the effect document.write can have on the document. The main point here is that, it obviously loads those scripts much faster and it is the only proper way to use document.write() without penalty. In contrast, see how bad document.write is at the bottom on Exhibit C below.

Test C : Nexus 7 - Chrome - 2G speed (adding an ES6 shim using document.write at the bottom).

The impact on page load or 'Document Complete' there is minimal, as it is a small script that doesn't do anything else other than being parsed. It however clearly delays 'Render' by 1-2s and 'Interactive' by 4-5 seconds already. That is the kind of harmful practice everyone should be told not to use at all.

For what it's worth, this may not be true in all UAs. It needs to stop observable DOM construction, and it needs to act as if parsing had been stopped, but you can in fact parse ahead speculatively if you want, and some UAs do that.
@bzbarsky

Correct. That's true of Chrome since Chrome PLT Improvements Q1 2013. According to that document, even if a script blocks it may speculatively download images if the network is idle (i.e. a light head). The important thing here, is that document.write() does not block assets in the head from being preloaded. Images are low priority anyway and won't start if you are busy with quite a few script + css downloads.

The combination of DOM construction blocking and speculative parsing is actually the problem here. The speculative parsing will load resources that are needed later in the page, delaying the load of the doc.written script.
@ojanvafai

Indeed as shown on C. But it's only a performance problem past the <body>, depending on how many script resources or images you have in between, but definitely not when prioritized in the <head> as demonstrated.

You can't just reprioritize the resource loads at that point because it's the upstream network bandwidth that's flooded.

Agreed past </head>. That's the proper recommendation to extract from this and promote.
Ultimately I would have no issue with preventing document.write() in the <body> entirely, even for same origin scripts. But again, in the <head>. I don't see any harm at all.

We were consistently seeing page load improvements of 10-30 seconds on many pages on 2G.

I can see that with any bottom document.write(s), especially if those also modify the DOM themselves, or would do worse by loading additional assets. Those are really obvious performance killer and an anti-pattern.

I totally get document.write() isn't ideal. But that's the only way that job gets done, at little to no cost, without a recourse to a more modular approach which in itself usually require an additional script and a performance cost in itself. (which mostly makes sense for a web app centric page as opposed to the average web site).

Clearly document.write() is not an enemy of performance when carefully used, and for the right reason.

[RByers]

As anyone who follows blink intent threads knows, I'm very concerned about web compat (often arguing that risking breaking even 0.01% of page views is unacceptable). There's no doubt that this is going to break some content. But when evaluating the compat cost (even in isolation before considering the benefits) we have to consider that this fixes 10% of pages loads on 2G that are otherwise so slow the user gives up waiting before anything paints. So to even be at neutral compat impact this would have to break at least 10% of 2G page loads. The initial evidence suggests it's well below that threshold. So this may be a rare intervention where we get to BOTH improve the user experience on many pages AND increase the number of pages that load correctly!

Of course there's still a risk of some class of pages being harmed more then they're helped. I suggest we focus on collecting examples of real pages that are broken with little benefit to see if there are any patterns that can be used to tweak the discrimination of this heuristic.

Also, interventions are premised on the idea that developers who follow best practices will not be impacted by them. @hexalys describes some use cases that seem pretty reasonable to me. Perhaps there's some way we can allow those to work without loosing most of the benefit?

[FremyCompany]

I think it is ok for an inline script to use document.write; technically an inline script is nearly identical to having the script tag in the html source.

[RByers]

Interventions generally have an opt-out. If there are some legit use cases, should this get an opt-out too - at least for now? Eg. What if the script loaded was previously listed as a <link rel=preload> target? @hexalys would that be enough to address your use cases? That would address the issue @ojanvafai describes with the load order getting hurt, but could obviously make things worse if the resource is large and usually not needed.

[michaelhood]

@RByers If we could expand that to a <link rel=preconnect>, it would cover my use cases: where the URI for the script tag is assembled dynamically at runtime (usually based on the host page's URL), but one of them is loaded on 100% of requests. Always from the same CDN domain, cross-origin.

[RByers]

I think it is ok for an inline script to use document.write; technically an inline script is nearly identical to having the script tag in the html source.

I'm not an expert here, but Ojan's argument above is that it's not - at least in Chrome. The script tag is exposed to the preload scanner (so can trigger loads early) while the doc.written script is not and so may block loading longer (especially due to all the later speculative resources that are now hogging the network).

Also the biggest problems come when one render-blocking script doc.writes another which doc.writes another and so on. As I understand it this can't happen with script tags, even when added via DOM APIs.

[hexalys]

Eg. What if the script loaded was previously listed as a target? @hexalys would that be enough to address your use cases?
@RByers

You mean to opt out of the restriction? It would for the multi version jQuery load, yes. Or the link rel=preconnect like @michaelhood said. Which would cover the 2nd case and CDN domains broadly. That's a good opt-out idea, I could get along with.

Also, should you decide to preload document.write(s). It's no too hard to get around it for case 2. Which I already do. If you look at my source on this site. I have two custom methods for document.write(s) and async loads for both contexts.

So I technically load this:
!Object.create && document.write('<script src="/cdn/lib/es5-shim.min.js"><\/script>');
as:
!Object.create&&cd.ws('es5-shim/4.5.9/es5-shim.',_);
which the preloader would not interfere with. Which seems a reasonable workaround.

Also the biggest problems come when one render-blocking script doc.writes another which doc.writes another and so on. As I understand it this can't happen with script tags, even when added via DOM APIs.

Well you can load synchronous ajax with similar effects. Though Chrome already get a "Synchronous XMLHttpRequest on the main thread" deprecation console warning to deter the practice.

[hexalys]

Temporary opt-out aside, and in consideration for a long term gradual deprecation of document.write(). I think I'd be only fair and useful to offer "some kind" of synchronous behavior alternative for polyfills.

A possible idea would be re-utilizing the existing 'defer' attribute and behavior. Right now, for parser-inserted scripts; async takes precedence over defer. However since there is no specified behavior for parser-inserted scripts with a defer flag yet. We could fill this gap with the following approach:

if (!document.write && !window.es7function){
  var script = document.createElement('script');
  script.src = 'es7-shim.js';
  script.defer = true; //parser-inserted true defer take precedence over async behavior
  document.head.appendChild(script);
}

The example would load a shim in an async fashion, but with a 'defer' priority, and in order. That removes the document.write() method from the equation while allowing newly non-blocking conditional scripts. The sync part comes at interactive, after which they are required to execute before DOMContentLoaded.

[roblarsen]

I think this is assuming that document.write() is only used for additive third party scripts like ad networks but one common use case of document.write is to fallback to a local script when a CDN fails. You can see an example of this from a very popular starter kit. This pattern has existed as far back as CDNs have been around and is probably encoded in a large number of websites.

Thanks for the pointer @matthewp. We actually opened an issue to figure out what to do about this proposed change.

FWIW, based on how long that pattern has been in H5BP and how popular H5BP has been I imagine the number of sites that have inherited the pattern from us directly is probably pretty big.

That said...

In your specific scenario this intervention not trigger because your fallback script is not cross-origin.

@PaulKinlan that's good to hear.

One thing, as you can see in the linked H5BP issue, there was some confusion on my (and others who brought it to our attention) part about the scope of this change as the list of conditions in your blog post doesn't mention cross-origin as being one of the conditions. Adding that in (as it's mentioned in this very issue) would better serve the time-deprived bulleted list scanners in your audience.

Thanks!

[domenic]

@KenjiBaheux can you give us a quick update on this intervention? Is it shipping in Chrome stable now? If so we should re-open discussions of merging whatwg/html#1400

[RByers]

This is in Chrome 55, so just recently Beta, stable early December.

[KenjiBaheux]

We are aiming at sending an intent to ship for Chrome 55.

I personally see our intent to ship process as a dialogue similar to a "letter of intent": it's a proposal for a course of action with a genuine interest in hearing all parties (e.g. share information about the benefits and risks, allow for additional information to be brought up, make an informed decision). Also, this intervention is definitely not trivial: we expect that we will learn a lot by trying and that we will have to refine what we have.

Regarding the Polyfills and CDN failures patterns, I would like to summarize the mitigations we currently have in place:

• To minimize breaking user functionality, the intervention does not block same site (i.e. hosts with matching eTLD+1) scripts.
• If the polyfills / CDN backups are hosted on a cross site host (i.e. different eTLD+1), the intervention slated for Chrome 55 will then trigger for users on 2G. We expect that these users will use the reload gesture to fix any significant breakage, in which case the intervention will not trigger. In addition, we are issuing async requests for the blocked resources which should mitigate breakage on subsequent navigations.
• Finally, with regards to the use of a script blocking document.write statement for these use cases, we believe that there are better alternatives to consider. However, we understand that there might be hurdles in practice and would like to learn more about these pain points. This issue is probably a better place to discuss this specific topic.

Regarding the idea of "blessing" resources that have been requested earlier via link rel=preload: we've been hoping that this would be enough to avoid the intervention altogether but we are definitely open to hear how often this works in practice (e.g. one should be able to track the impact via the Intervention header).

I understand that for the CDN backup and polyfill use cases, rel=preload is not ideal (risk of superfluous requests) nor always practical (e.g. the sample with the dynamically determined version number). The question of allowing sub resources that have been warmed up via rel=preconnect is interesting. One factor would be the relative impact of preconnect on the overall fetch cost.

Updates

• 10/25/2016: fixed incorrect usage of the term "cross origin / same origin" when we meant "cross site / same site (i.e. host with different/matching eTLD+1)".

[domenic]

Thanks for the info @KenjiBaheux! Although...

same origin (in the eTLD+1 meaning)

This is pretty confusing; probably you mean "same site". "Same origin" has a specific definition that is definitely not eTLD+1.

[KenjiBaheux]

@domenic Apologies for using the wrong term.
I will try to fix all the existing documentation and upcoming communication.

I'm assuming that same site == same eTLD+1 is not necessarily a widely understood definition.
So, I'll probably write it as "same site (i.e. host with matching eTLD+1)", Let me know if this is better.

[domenic]

Sounds great to me :)

[cramforce]

The IntersectionObserver spec calls it similar origin, which might be the
same thing.
https://html.spec.whatwg.org/multipage/browsers.html#unit-of-related-similar-origin-browsing-contexts

On Oct 24, 2016 7:40 PM, "Domenic Denicola" notifications@github.com
wrote:

Sounds great to me :)

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#17 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAFeTz0gIvVOIZUbiXJ7Ufqkc3pxVevKks5q3WwNgaJpZM4IN2lZ
.

[KenjiBaheux]

Yes, we are aiming at a launch in Chrome 55 (for connections advertised as
2G, as opposed to effectively 2G connections such as weak 3G).

On Wed, Oct 19, 2016 at 2:05 AM Domenic Denicola notifications@github.com
wrote:

@KenjiBaheux https://github.com/KenjiBaheux can you give us a quick
update on this intervention? Is it shipping in Chrome stable now? If so we
should re-open discussions of merging whatwg/html#1400
whatwg/html#1400

—
You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub
#17 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AGD3CvzN-jb2unRbjg7KPR1C-lRfk6dEks5q1PxNgaJpZM4IN2lZ
.

[KenjiBaheux]

As an FYI, we've just sent our intent to ship and started an FAQ as well as a form to collect feedback / suggestions for the FAQ.

[zeg]

My site's javascript script is hosted in a different domain (cdn)

And must be loaded synchronously to properly render the content

And that is a huge project I can not change all of them to asynchronous load

Please you developers to tell me how I should do???

[jakearchibald]

I wrote about how you can use an iframe + document.write to stream HTML https://jakearchibald.com/2016/fun-hacks-faster-content/#using-iframes-and-documentwrite-to-improve-performance

The HTML spec currently says that scripts shouldn't execute in this case (issue), but Edge, Chrome & Safari all do, so it's possible the spec will change.

Since these document.writes happen after the document has loaded (there's no network stream feeding into the parser), it feels like it should be exempt from this intervention.

[shivanigithub]

@jakearchibald : The intervention only works for scripts that are in the main frame, so any document.written script in an iframe will be exempt from the intervention.

[pfwd]

It might be worth having some more definition around what is a 'Slow Connection'.
A weak 3G connection can be just as bad if not worse than a strong 2G connection.
Ideally we need to detect the signal strength within each band but I'm not sure if that's possible

[acsteitz]

There is a lot of uproar in public forums about this intervention. Not because people on 2G are ending up with broken pages, but because people on FAST connections are ending up with them.

Whatever mechanism has been installed for this intervention, it doesn't work properly. I get the warning in DevTools that scripts have been blocked even though I am on a solid WiFi connection.
Ookla speed test: Ping: 37 ms; Download: 13.29 Mbps; Upload: 14.47 Mbps.
Chrome Version 55.0.2883.87 m (64-bit)
Windows 10 Pro (10.0.14393)

Bootstrap.js:214 A Parser-blocking, cross-origin script, https://cdn.tt.omtrdc.net/cdn/target.js, is invoked via document.write. This may be blocked by the browser if the device has poor network connectivity. See https://www.chromestatus.com/feature/5718547946799104 for more details.
sf @ Bootstrap.js:214
Bootstrap.js:172 A Parser-blocking, cross-origin script, https://humana.tt.omtrdc.net/m2/humana/mbox/ajax?mboxHost=myhumana.humana.c…oxReferrer=https%3A%2F%2Fwww.humana.com%2Fservice-agreement&mboxVersion=60, is invoked via document.write. This may be blocked by the browser if the device has poor network connectivity. See https://www.chromestatus.com/feature/5718547946799104 for more details.

[acsteitz]

BTW, I do not work for Humana. I am a customer and this broken intervention prevents me from being able to LOGOUT. I have to wait for my session to TIMEOUT instead which is OK if I am on my own computer but if I happen to be on someone else's computer or, even worse, at a public computer (library, kiosk, etc) I have to either sit at the computer until I know the session has timed-out or risk someone else getting into my medical claims. Thanks a lot! I wonder if there are any banking sites or other "high risk/value" sites that are affected.

I realize you did not create the Humana web site but this broken intervention has CAUSED this potential invasion of privacy. Since I know about it now, I can avoid it but what about the millions of people who don't know about this problem who could end up exposing their personal information because of this change that was pushed through without enough REAL WORLD research?

[acsteitz]

I had not thought about the potential exposure for other people until I wrote the above. Sorry to do this, but given what I just realized, I am going to have to publish my concerns to a much broader audience. This MUST get fixed post haste.

[TechRsch]

My hardwired 100Mb LAN connection is throwing this error.

[bryanmcquade]

Replying to acsteitz:

The console warning shows up in cases where the intervention would have triggered on slow connections, even if you are on a fast connection, to help developers to identify cases where users on slow connections would encounter blocking. So the warning is just that: a warning - it doesn't indicate that the intervention actually triggered in your case.

If you see "A Parser-blocking, cross-origin script, ..., is invoked via document.write. This may be blocked by the browser if the device has poor network connectivity. See https://www.chromestatus.com/feature/5718547946799104 for more details." in the console it indicates that the script may be blocked for users on slow connections, but not necessarily that the script was blocked for your connection. We currently only block on 2G so this should not be triggering if you are on a fast connection.

If the Humana site is failing to support logout on a fast connection, that's likely due to a bug on their site (or possibly a different Chrome bug) rather than this intervention, as the intervention should be having no effect while on a fast connection.

To force disable the intervention, just to be certain, you can go to chrome://flags/ and choose 'Disabled' for 'Block scripts loaded via document.write'. If you are already on a fast connection this should be a no-op, but it can't hurt to try. If you see different behavior with the intervention disabled (i.e. the 'logout' option starts to work) then please let us know.

[TechRsch]

Reply to bryanmcquade:

As I have mentioned, I am on a 100Mb hardwired LAN connection. I have had problems running videos on Chrome. I disabled the flag as you suggested. And, now they work. The conclusion is that the intervention WAS triggered and DID interfere with Chrome's operation on a high-speed connection.

[acsteitz]

Reply to bryanmcquade:

I am ashamed! I have taken down my FB and Google+ posts. Some people claim I don't admit when I am wrong. That is not true. I have done it both times. LOL!

I did not know about the flag. I promise I searched for a way to disable it but the first xx pages of results only had people discussing fixes for web devs to get their sites fixed. I set the flag to "disabled" and the logout function is still not available in Chrome 55. However, it worked in Chrome 54 and still works in other browsers.

I have a degree in Physics so I am totally aware of the concept that correlation does not equal causation but without knowing about the flag, all the other indicators pointed at this intervention. Mea culpa.

Also, although I do not work at Humana, I worked at a wholly owned subsidiary until Jan 2010. I still know some people at Humana and will alert them to this problem today so they can research and fix it from their end.

[acsteitz]

Reply to bryanmcquade:

Even though setting the flag did not solve my problem, TechRsch seems to have proven (well, at least gathered more evidence) that this intervention does still have issues and could actually cause the type of problem I experience at Humana.com. Seems that this intervention still needs some real world testing/data gathering.

[RByers]

However, it worked in Chrome 54 and still works in other browsers.

Sorry about this regression! Please file a bug at crbug.com/wizard providing precise reproduction steps for what worked in Chrome 54 but is now failing in Chrome 55. Our QA team will repeat your steps on a variety of Chrome builds to "bisect" down to the single commit responsible for the change in behavior, and we can take the issue from there.

[RByers]

As I have mentioned, I am on a 100Mb hardwired LAN connection. I have had problems running videos on Chrome. I disabled the flag as you suggested. And, now they work. The conclusion is that the intervention WAS triggered and DID interfere with Chrome's operation on a high-speed connection.

If this is true there must be a bug somewhere. Please file a bug at crbug.com/wizard with precise reproduction steps so that we can investigate.

[ddimitrop]

Hi,
I have been wondering about how could I test my site for the effects of the intervention.
Would the effects be triggered when I use the devtools network throttling (down to 2G)?
I can see warnings but it looks that the scripts are still run on Chrome 56.

[shivanisharma2]

Go to about:flags and enable the flag "Block scripts loaded via document.write". This will enable the intervention irrespective of the connection type.

[RByers]

First shipped in Chrome 55