eng (and PM) emails
Summary
Right now, the preload scanner will send fetches for script tags regardless of type/language, but the script loader will ignore them. The two systems should have the same semantics, and we should not be initiating fetches for scripts we will not use.
This was done in https://codereview.chromium.org/2099853002/ but was reverted due to a possibility of compat risks.
Motivation
This could save data for users who navigate to sites with a lot of custom script tags that are post-processed (like type=”text/template”). The original motivation for the change was a problem with mod_pagespeed pages double downloading scripts due to the preload scanner fetching them, and their post-processing doing a fetch after the resource is evicted from the memory cache.
Compatibility Risk
There is some use of this feature to ping servers. See crbug.com/626205 for the reason the original CL was reverted. The specific tag used as an example in the bug is:
<script type="text/template" src="https://www.google.com/ping"></script>
Alternative implementation suggestion for web developers
The use case of using invalid scripts to ping servers is adequately covered by the sendBeacon API.
Usage information from UseCounter
No UseCounter.
OWP launch tracking bug
Entry on the feature dashboard
No entry due to small feature.
Requesting approval to remove too?
Yes
The preload scanner doesn't have a spec (yet?) but at least https://html.spec.whatwg.org/multipage/scripting.html#prepare-a-script bails out before the fetch for an invalid type/language, so far so good.
Do you have some idea about the scope of the compat risk? crbug.com/626205 was filed within a week of the change being made, so that's not super encouraging. Can you check what Edge does?
As for alternatives, the sendBeacon API requires scripts to run, and it seems plausible that people are using this trick because it happens as early as possible. If the issue is fixed, is there any declarative alternative?
On Thu, Jul 7, 2016 at 9:28 AM, Philip Jägenstedt <foo...@chromium.org> wrote:The preload scanner doesn't have a spec (yet?) but at least https://html.spec.whatwg.org/multipage/scripting.html#prepare-a-script bails out before the fetch for an invalid type/language, so far so good.Yeah, this feels like a bug-fix to match the spec to me.Do you have some idea about the scope of the compat risk? crbug.com/626205 was filed within a week of the change being made, so that's not super encouraging. Can you check what Edge does?I guess it's not really possible to have a good metric for this right? I mean we can measure how often we are currently downloading scripts we should skip, but we can expect the vast majority of those cases won't break anything when we stop downloading.
As for alternatives, the sendBeacon API requires scripts to run, and it seems plausible that people are using this trick because it happens as early as possible. If the issue is fixed, is there any declarative alternative?Yoav mentions in the bug that people often use a 1x1 transparent image for this, or just an empty script (with a legitimate script type). Those also seem like reasonable alternatives - especially since I assume they work reliably across all browsers, relying only on standard behavior.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
The pagespeed cases will be positively affected by this change. They are sites running our defer_javascript filter, and the current behavior means JavaScript isn't deprioritized as much as it should be.
So I'm in favor of this change!
The pagespeed cases will be positively affected by this change. They are sites running our defer_javascript filter, and the current behavior means JavaScript isn't deprioritized as much as it should be.
So I'm in favor of this change!
LGTM2
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
document.write(\"<script type=\\\"text/java` 1\"\\\" src=\\\"\" +`\"H!` p# + \"\\\"></` A\">\");
In any case, I will add the deprecation notice.
LGTM3
LGTM2
☆PhistucK
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
LGTM3
LGTM2
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
Hi,
I am the author and main developer of Brython, an implementation of Python for the browser. It uses <script type="text/python">
to embed scripts written in Python instead of Javascript.
Currently, a Python script can be loaded by <script type="text/python" src="script.py">. Someone just reported the
deprecation warning on Chrome.
Does this mean that this will no longer be possible ? If so it would be terribly bad news for the project. I think that text/python
should not be considered an invalid type attribute.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
I understand that invalid type/language would get ignored. But what about script tag with no type attribute (or a blank one).
Right, thank you for the clarifications, I forgot about the XMLHttpRequest versus script fetch differences for a second.I actually search for an as value and could not find it, I guess it is not standardized yet.