Enable `as` based priorities for <link rel=preload>

Enable `as` based priorities for <link rel=preload>

The `as` attribute on <link rel=preload> was implemented as a placeholder, but didn't really do anything.

This CL adds support for true resource prioritization based on the `as` attribute, as well as LinkLoader unit tests for preload, and fixing a bug related to preload triggering a download even before it was added to the document.
 
BUG=471199
Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=195532

[Yoav Weiss, 2015-05-19 02:37:37]

yoav@yoav.ws changed reviewers:
+ mkwst@chromium.org

[Yoav Weiss, 2015-05-19 02:38:49]

Hey Mike :)

Here's something I wrote on the flight. Can you take a look?

Let me know if you think it's too big for a single CL and I'll split it.

[Mike West, 2015-05-19 06:37:30]

LGTM % nits. This is still behind a flag, right?

https://codereview.chromium.org/1141883003/diff/1/Source/core/fetch/ResourceF...
File Source/core/fetch/ResourceFetcher.cpp (right):

https://codereview.chromium.org/1141883003/diff/1/Source/core/fetch/ResourceF...
Source/core/fetch/ResourceFetcher.cpp:208: // TODO(yoav): Should we give preload
its own context?
*shrug* Talk to Anne. It's not clear to me how it is different from `prefetch`,
TBH.

https://codereview.chromium.org/1141883003/diff/1/Source/core/loader/LinkLoad...
File Source/core/loader/LinkLoaderTest.cpp (right):

https://codereview.chromium.org/1141883003/diff/1/Source/core/loader/LinkLoad...
Source/core/loader/LinkLoaderTest.cpp:58: for (auto& testCase : cases) {
Nit: `const auto&`.

[Yoav Weiss, 2015-05-19 10:47:37]

On 2015/05/19 06:37:30, Mike West (holiday in DE) wrote:
> LGTM % nits. This is still behind a flag, right?

Yup, LinkRelAttribute makes sure that rel=preload is only recognized when the
flag is on.

> 
>
https://codereview.chromium.org/1141883003/diff/1/Source/core/fetch/ResourceF...
> File Source/core/fetch/ResourceFetcher.cpp (right):
> 
>
https://codereview.chromium.org/1141883003/diff/1/Source/core/fetch/ResourceF...
> Source/core/fetch/ResourceFetcher.cpp:208: // TODO(yoav): Should we give
preload
> its own context?
> *shrug* Talk to Anne. It's not clear to me how it is different from
`prefetch`,
> TBH.

Looking at the spec, a preload context was added. Changed the TODO accordingly.
A `preload` is different from a `prefetch` in that it applies to current
navigation, where `prefetch` applies to the next one.
So a CSP user may want to apply different policies for them (e.g. this page can
preload fonts from incrediblefonts.com, while the next page won't need them).

> 
>
https://codereview.chromium.org/1141883003/diff/1/Source/core/loader/LinkLoad...
> File Source/core/loader/LinkLoaderTest.cpp (right):
> 
>
https://codereview.chromium.org/1141883003/diff/1/Source/core/loader/LinkLoad...
> Source/core/loader/LinkLoaderTest.cpp:58: for (auto& testCase : cases) {
> Nit: `const auto&`.

done

[Mike West, 2015-05-19 11:16:25]

On 2015/05/19 at 10:47:37, yoav wrote:
> Looking at the spec, a preload context was added. Changed the TODO
accordingly.
> A `preload` is different from a `prefetch` in that it applies to current
navigation, where `prefetch` applies to the next one.
> So a CSP user may want to apply different policies for them (e.g. this page
can preload fonts from incrediblefonts.com, while the next page won't need
them).

I still don't understand the difference. Either way, the page is saying "Go load
this thing.", right?

*shrug* I trust that people who know things about performance and loading and
etc understand why we need this distinction, but it's not clear to me what we'd
tell developers from a security perspective that would differentiate between the
two use cases.

[Yoav Weiss, 2015-05-19 11:20:49]

On 2015/05/19 11:16:25, Mike West (holiday in DE) wrote:
> On 2015/05/19 at 10:47:37, yoav wrote:
> > Looking at the spec, a preload context was added. Changed the TODO
> accordingly.
> > A `preload` is different from a `prefetch` in that it applies to current
> navigation, where `prefetch` applies to the next one.
> > So a CSP user may want to apply different policies for them (e.g. this page
> can preload fonts from http://incrediblefonts.com, while the next page won't
need
> them).
> 
> I still don't understand the difference. Either way, the page is saying "Go
load
> this thing.", right?
> 

The page is saying "go load this thing for later on in current navigation" (for
preload), and "go load this thing for next navigation" (for prefetch).

> *shrug* I trust that people who know things about performance and loading and
> etc understand why we need this distinction, but it's not clear to me what
we'd
> tell developers from a security perspective that would differentiate between
the
> two use cases.

Basically, if you want to enable the browser to preload assets for the current
navigation (same as subresource, only not disfunctional), you want devs to add a
CSP directive that permits it.
And if you want the enable the browser to prefetch assets for the next followup
navigations (prefetch), you (probably) want a separate directive.
But let's discuss that further in the followup CL to add the actual new context.

[Yoav Weiss, 2015-05-19 14:06:48]

The CQ bit was checked by yoav@yoav.ws

[Yoav Weiss, 2015-05-19 14:06:49]

The patchset sent to the CQ was uploaded after l-g-t-m from mkwst@chromium.org
Link to the patchset: https://codereview.chromium.org/1141883003/#ps20001
(title: "Review comments")

[commit-bot: I haz the power, 2015-05-19 14:07:05]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1141883003/20001

[commit-bot: I haz the power, 2015-05-19 14:10:23]

Committed patchset #2 (id:20001) as
https://src.chromium.org/viewvc/blink?view=rev&revision=195532