Riot: Fetching scripts with an invalid type/language attributes is going to be removed in Chrome 56

[jrx-jsj]

Help us to manage our issues by answering the following:

1. Describe your issue:

When using scripts for importing uncompiled RIOT tags in a HTML page, we are getting the following notice in Chrome 55:

Fetching scripts with an invalid type/language attributes is deprecated and will be removed in M56, around January 2017. See https://www.chromestatus.com/features/5760718284521472 for more details.

1. Can you reproduce the issue?

Every webpage using uncompiled RIOT tags will trigger the notice. You can check it in Timer example

1. On which browser/OS does the issue appear?

Notice triggered on Chrome 55. Feature is planned to be removed on Chrome 56.

1. Which version of Riot does it affect?

Latest.

1. How would you tag this issue?

   • [x] Question
   • [ ] Bug
   • [x] Discussion
   • [ ] Feature request
   • [ ] Tip
   • [ ] Enhancement
   • [ ] Performance

[cognitom]

Hi @jrx-jsj, thanks for reporting. As my understanding, the purpose of this change is to prevent "double downloads".

1. prefetching by browser (deprecate in Chrome 56)
2. ajax fetching by Riot

So, we'll get no effect on it, I think. If you find any other side effects, let us know.

[GianlucaGuarini]

Riot uses ajax requests to load script tags so it should not be affected by the chrome change @jrx-jsj thanks anyway

[zcorpan]

In https://github.com/riot/riot/issues/2140 I suggest that this should be changed anyway, even though nothing will break, because:

• currently it is issuing two requests, which is bad for performance.
• Using the src attribute with an unsupported type is invalid HTML.

See that issue for a proposed fix.

[cognitom]

@zcorpan thanks.
I saw that CoffeeScript uses data-src, even though I didn't see in others.
http://coffeescript.org/#1.9.2

In the point of readability and analogy to normal script, I think we shouldn't move to data-src. We can just add data-src as an alias to src. Thoughts? @GianlucaGuarini

[zcorpan]

Alternatively you could use something other than script altogether. I just thought it would be the simplest change. But you just need to grab a string from somewhere and have it be convenient to author it in the HTML, right? You could for example use a custom element:

<riot-tag src="dbmon.tag"></riot-tag>

Edit: (however this can't be used in head)

[cognitom]

In-browser compilation is actually a kind of tools for the beginners. So data-src, or <riot-tag> could be an overload for them to understand. I'm worried about it...

Anyway here's a quick PR #2141.
How about just adding one line at the end of this section in our documentation?

Note: you can also use data-src attribute to prevent double fetching.

[cognitom]

I'd like to add a link to an external page which explains double fetching.
@zcorpan pls let me know, if you know any good resource about it.

[csharrison]

Hi cognitom, the chromestatus entry should be the go-to place:
https://www.chromestatus.com/feature/5760718284521472

Unfortunately it has nothing about double fetching it, but I can add a sentence to the description.

[GianlucaGuarini]

I still don't get it... we parse the DOM to find <script> nodes with the attribute type="riot/tag". I don't get why should we care if chrome fetches these scripts or not since we load their content via ajax directly in riot anyway. Will chrome remove all these <script> tags from the DOM?

[csharrison]

Today, Chrome will speculatively look ahead of the HTML parser and preload any script it finds, regardless of type. This means Chrome will download those scripts with type "riot/tag" twice: once during the preload stage and once when the library actually initiates the XHR.

We are tightening the restrictions here so we only speculatively fetch resources with valid types (i.e. ones that will actually execute), which will stop the double download in this case.

[rsbondi]

This sounds like a good thing.

[csharrison]

It is a good thing, but we haven't shipped it yet :)

We are aiming to remove the fetch in Chrome 56. If riot moves away from this model today, the double downloading will stop in Chrome 55, along with Safari, Firefox, etc.

[GianlucaGuarini]

Ok so this only means that all the script tags will not be fetched by Chrome automatically but only by riot when it will be needed by calling riot.compile so that's why I guess we don't need to change anything. This change does not affect riot it just fixes a wrong chrome behavior. Do we really need also data-src at this point?

[cognitom]

I thought so, too. They said "Deprecate all fetches with invalid type/language".
Is this correct?

• now: prefetch + fetch via ajax
• future: prefetch(deprecate) fetch via ajax

[csharrison]

As I mentioned in my previous comment, many other browsers still make this extra fetch, including the current version of Chrome. zcorpan also mentioned this in https://github.com/riot/riot/issues/2132#issuecomment-265434536.

[cognitom]

Ah, I see. I've confirmed "double fetching" in Firefox, too.

[GianlucaGuarini]

Ok so we don't need to change anything..I would like to leave the src attribute, and if there will be a prefetch, the ajax request will just use the cache to retrieve the script contents

[cognitom]

@GianlucaGuarini just curious, why Firefox says 200 at the second fetch?

[rsbondi]

In edge and chrome I see a double request, but the second request returns status 304, so appears to be only a single fetch as confirmed by the timeline, sounds like the new chrome behavior is what makes the most sense

[cognitom]

Gotcha, the case above is just because of overlapping.

[GianlucaGuarini]

@cognitom http://plnkr.co/edit/l5nzSwQN01gyE01DoCei?p=preview check this example. The file gets retrieved from the cache if the riot.compile gets called a bit later

[cognitom]

@GianlucaGuarini it could depend on the latency and the size of the page.

Anyway I have no preference to support data-src or not. It could be worth for pros in some rare case, but pros might not use in-browser compiler. On the other hand beginners may not care about it.

[zcorpan]

The prefetch and the XHR fetch can't use the same connection (if the XHR starts before the prefetch is finished), because a script prefetch and XHR fetch have different rules/semantics in the engine. That's why there is a double request.