Chromium Code Reviews
|
|
Chromium Code Reviews
Issue
2424943002:
Add ReferrerPolicy support to preload (Closed)
|
Created:
4 years, 2 months ago by Yoav Weiss Modified:
4 years, 1 month ago CC:
blink-reviews, blink-reviews-html_chromium.org, chromium-reviews, dglazkov+blink, gavinp+prerender_chromium.org, gavinp+loader_chromium.org, Nate Chapin, kinuko+watch, loading-reviews_chromium.org, loading-reviews+parser_chromium.org, tyoshino+watch_chromium.org Target Ref:
refs/pending/heads/master Project:
chromium Visibility:
Public. |
DescriptionAdd ReferrerPolicy support to preload
This CL adds referrerpolicy attribute support to link rel preload.
Intent to implement and ship:
https://groups.google.com/a/chromium.org/d/msg/blink-dev/LukPJ86fcs8/RX_dsbUiCAAJ
BUG=595099
Committed: https://crrev.com/93f84740e06572bd05ca465067d7f98c24c4c514
Cr-Commit-Position: refs/heads/master@{#429567}
Patch Set 1 #
Total comments: 6
Patch Set 2 : rebase #Patch Set 3 : Review comments #Patch Set 4 : Fix test #Patch Set 5 : Fix test. Again #
Total comments: 11
Patch Set 6 : Removed headers implementation and review comments #Patch Set 7 : Removed legacy calls #Patch Set 8 : Test fix #Messages
Total messages: 64 (40 generated)
The CQ bit was checked by yoav@yoav.ws to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
Description was changed from ========== Add ReferrerPolicy support to preload BUG= ========== to ========== Add ReferrerPolicy support to preload This CL adds referrerpolicy attribute support to link rel preload. BUG= ==========
yoav@yoav.ws changed reviewers: + estark@chromium.org
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: Try jobs failed on following builders: mac_chromium_compile_dbg_ng on master.tryserver.chromium.mac (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_comp...) mac_chromium_rel_ng on master.tryserver.chromium.mac (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_...)
Hey Emily, (On a plane with shaky internet so apologies if the patch is slightly messy, description not clear, etc). I had an hour to kill so took a stab at referrerpolicy support for preload. Let me know what you think :)
On 2016/10/17 17:01:45, Yoav Weiss wrote: > Hey Emily, > > (On a plane with shaky internet so apologies if the patch is slightly messy, > description not clear, etc). > > I had an hour to kill so took a stab at referrerpolicy support for preload. > > Let me know what you think :) Also, I'll rebase once I land somewhere with decent internet...
Thank you!!! Just a few comments inline. I also want to note about the LinkHeader changes that the referrerpolicy attribute isn't spec'ed anywhere for the header; I guess it's okay to implement it anyway...? https://codereview.chromium.org/2424943002/diff/1/third_party/WebKit/Source/c... File third_party/WebKit/Source/core/html/parser/HTMLPreloadScannerTest.cpp (right): https://codereview.chromium.org/2424943002/diff/1/third_party/WebKit/Source/c... third_party/WebKit/Source/core/html/parser/HTMLPreloadScannerTest.cpp:631: "<link rel=preload as=image referrerpolicy='origin-when-crossorigin' " perhaps a test case with `referrerpolicy='not-a-valid-policy'`? https://codereview.chromium.org/2424943002/diff/1/third_party/WebKit/Source/c... File third_party/WebKit/Source/core/loader/LinkLoader.cpp (right): https://codereview.chromium.org/2424943002/diff/1/third_party/WebKit/Source/c... third_party/WebKit/Source/core/loader/LinkLoader.cpp:418: LinkCalledFromMarkup, errorOccurred, nullptr, ReferrerPolicyDefault)); This should be `referrerPolicy` instead of `ReferrerPolicyDefault`, I think? (Would one of the unit tests catch this?) https://codereview.chromium.org/2424943002/diff/1/third_party/WebKit/Source/c... third_party/WebKit/Source/core/loader/LinkLoader.cpp:432: FetchRequest linkRequest(ResourceRequest(document.completeURL(href)), Presumably we also want to set a referrer policy on this request, but I'm thinking that you're intentionally just covering preload (not prefetch) in this CL? https://codereview.chromium.org/2424943002/diff/1/third_party/WebKit/Source/c... File third_party/WebKit/Source/core/loader/LinkLoaderTest.cpp (right): https://codereview.chromium.org/2424943002/diff/1/third_party/WebKit/Source/c... third_party/WebKit/Source/core/loader/LinkLoaderTest.cpp:234: resource->resourceRequest().requestContext()); Looks like this is missing an assertion about `expectedReferrerPolicy`.
The CQ bit was checked by yoav@yoav.ws to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: Try jobs failed on following builders: win_chromium_x64_rel_ng on master.tryserver.chromium.win (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_x64_...) win_clang on master.tryserver.chromium.win (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.win/builders/win_clang/builds/...)
The CQ bit was checked by yoav@yoav.ws to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
https://codereview.chromium.org/2424943002/diff/1/third_party/WebKit/Source/c... File third_party/WebKit/Source/core/html/parser/HTMLPreloadScannerTest.cpp (right): https://codereview.chromium.org/2424943002/diff/1/third_party/WebKit/Source/c... third_party/WebKit/Source/core/html/parser/HTMLPreloadScannerTest.cpp:631: "<link rel=preload as=image referrerpolicy='origin-when-crossorigin' " On 2016/10/18 04:55:54, estark wrote: > perhaps a test case with `referrerpolicy='not-a-valid-policy'`? Added https://codereview.chromium.org/2424943002/diff/1/third_party/WebKit/Source/c... File third_party/WebKit/Source/core/loader/LinkLoader.cpp (right): https://codereview.chromium.org/2424943002/diff/1/third_party/WebKit/Source/c... third_party/WebKit/Source/core/loader/LinkLoader.cpp:418: LinkCalledFromMarkup, errorOccurred, nullptr, ReferrerPolicyDefault)); On 2016/10/18 04:55:54, estark wrote: > This should be `referrerPolicy` instead of `ReferrerPolicyDefault`, I think? > (Would one of the unit tests catch this?) yes and yes. (and now that the tests have an expected value, they actually do)
> > https://codereview.chromium.org/2424943002/diff/1/third_party/WebKit/Source/c... > third_party/WebKit/Source/core/loader/LinkLoader.cpp:432: FetchRequest > linkRequest(ResourceRequest(document.completeURL(href)), > Presumably we also want to set a referrer policy on this request, but I'm > thinking that you're intentionally just covering preload (not prefetch) in this > CL? Yeah, I didn't want to expand into prefetch in this CL, but I can definitely followup with prefetch support. > > https://codereview.chromium.org/2424943002/diff/1/third_party/WebKit/Source/c... > File third_party/WebKit/Source/core/loader/LinkLoaderTest.cpp (right): > > https://codereview.chromium.org/2424943002/diff/1/third_party/WebKit/Source/c... > third_party/WebKit/Source/core/loader/LinkLoaderTest.cpp:234: > resource->resourceRequest().requestContext()); > Looks like this is missing an assertion about `expectedReferrerPolicy`. indeed!
Description was changed from ========== Add ReferrerPolicy support to preload This CL adds referrerpolicy attribute support to link rel preload. BUG= ========== to ========== Add ReferrerPolicy support to preload This CL adds referrerpolicy attribute support to link rel preload. BUG= 595099 ==========
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: Try jobs failed on following builders: win_chromium_rel_ng on master.tryserver.chromium.win (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_rel_...)
The CQ bit was checked by yoav@yoav.ws to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was checked by yoav@yoav.ws to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: This issue passed the CQ dry run.
lgtm, thanks!
The CQ bit was checked by yoav@yoav.ws
The CQ bit was checked by yoav@yoav.ws
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was unchecked by commit-bot@chromium.org
Try jobs failed on following builders: chromium_presubmit on master.tryserver.chromium.linux (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.linux/builders/chromium_presub...)
yoav@yoav.ws changed reviewers: + jochen@chromium.org, mkwst@chromium.org
Mike or Jochen, can you take a look?
https://codereview.chromium.org/2424943002/diff/80001/third_party/WebKit/Sour... File third_party/WebKit/Source/core/html/HTMLLinkElement.cpp (right): https://codereview.chromium.org/2424943002/diff/80001/third_party/WebKit/Sour... third_party/WebKit/Source/core/html/HTMLLinkElement.cpp:83: m_referrerPolicy = value; Where do you take the page's referrer policy into account? Shouldn't the request fall back to that policy if no policy is explicitly set for the element? https://codereview.chromium.org/2424943002/diff/80001/third_party/WebKit/Sour... File third_party/WebKit/Source/core/html/parser/HTMLPreloadScanner.cpp (right): https://codereview.chromium.org/2424943002/diff/80001/third_party/WebKit/Sour... third_party/WebKit/Source/core/html/parser/HTMLPreloadScanner.cpp:363: SecurityPolicy::referrerPolicyFromStringWithLegacyKeywords( Why do we accept legacy keywords on the `referrerpolicy` attribute? I thought we only accepted those for `<meta>`? https://codereview.chromium.org/2424943002/diff/80001/third_party/WebKit/Sour... File third_party/WebKit/Source/core/loader/LinkLoader.cpp (right): https://codereview.chromium.org/2424943002/diff/80001/third_party/WebKit/Sour... third_party/WebKit/Source/core/loader/LinkLoader.cpp:386: SecurityPolicy::referrerPolicyFromStringWithLegacyKeywords( Same question regarding legacy. https://codereview.chromium.org/2424943002/diff/80001/third_party/WebKit/Sour... third_party/WebKit/Source/core/loader/LinkLoader.cpp:425: SecurityPolicy::referrerPolicyFromStringWithLegacyKeywords( Ditto. https://codereview.chromium.org/2424943002/diff/80001/third_party/WebKit/Sour... File third_party/WebKit/Source/platform/network/LinkHeaderTest.cpp (right): https://codereview.chromium.org/2424943002/diff/80001/third_party/WebKit/Sour... third_party/WebKit/Source/platform/network/LinkHeaderTest.cpp:154: {"</images/cat.jpg>; rel=preload;referrerpolicy=somevalue", true, I guess this is a reasonable addition, but it needs to be specified somewhere. We should probably also be taking the `referrer-policy` header into account (which, again, is an argument for specifying the behavior somewhere :) ). https://codereview.chromium.org/2424943002/diff/80001/third_party/WebKit/Sour... third_party/WebKit/Source/platform/network/LinkHeaderTest.cpp:155: "/images/cat.jpg", "preload", "", "", "somevalue"}, I don't understand how this test works. You've added a `referrerPolicy` value, but it doesn't look like you're checking it anywhere? And you haven't added the value to any other item in the list?
https://codereview.chromium.org/2424943002/diff/80001/third_party/WebKit/Sour... File third_party/WebKit/Source/core/html/HTMLLinkElement.cpp (right): https://codereview.chromium.org/2424943002/diff/80001/third_party/WebKit/Sour... third_party/WebKit/Source/core/html/HTMLLinkElement.cpp:83: m_referrerPolicy = value; On 2016/10/23 05:25:46, Mike West wrote: > Where do you take the page's referrer policy into account? Shouldn't the request > fall back to that policy if no policy is explicitly set for the element? It's done at the consumers of HTMLLinkElement::referrerPolicy() (so, inside LinkLoader). Doing it here might be better when support is extended beyond just preload. https://codereview.chromium.org/2424943002/diff/80001/third_party/WebKit/Sour... File third_party/WebKit/Source/core/html/parser/HTMLPreloadScanner.cpp (right): https://codereview.chromium.org/2424943002/diff/80001/third_party/WebKit/Sour... third_party/WebKit/Source/core/html/parser/HTMLPreloadScanner.cpp:363: SecurityPolicy::referrerPolicyFromStringWithLegacyKeywords( On 2016/10/23 05:25:46, Mike West wrote: > Why do we accept legacy keywords on the `referrerpolicy` attribute? I thought we > only accepted those for `<meta>`? I just used whatever HTMLImageElement is using, and don't know the historical events that brought said legacy mode upon us. Scanning the code, it looks like the HTTP header and workers are not accepting the legacy keywords, but the meta and attributes do accept it. estark is likely to have way more opinions on the matter than myself. https://codereview.chromium.org/2424943002/diff/80001/third_party/WebKit/Sour... File third_party/WebKit/Source/platform/network/LinkHeaderTest.cpp (right): https://codereview.chromium.org/2424943002/diff/80001/third_party/WebKit/Sour... third_party/WebKit/Source/platform/network/LinkHeaderTest.cpp:154: {"</images/cat.jpg>; rel=preload;referrerpolicy=somevalue", true, On 2016/10/23 05:25:46, Mike West wrote: > I guess this is a reasonable addition, but it needs to be specified somewhere. > We should probably also be taking the `referrer-policy` header into account > (which, again, is an argument for specifying the behavior somewhere :) ). I considered it as a "link-extension" defined in https://tools.ietf.org/html/rfc5988#section-5 (Similar to what we do with `as` and the way the `nopush` attribute is being used (even if browsers don't really need to support it). Do you think we need to define it (and other new attributes) explicitly? If so, I'll be happy do that. I assumed the header is being taken into account in the code that consumes that header (as the document's referrer policy). A test wouldn't hurt tho https://codereview.chromium.org/2424943002/diff/80001/third_party/WebKit/Sour... third_party/WebKit/Source/platform/network/LinkHeaderTest.cpp:155: "/images/cat.jpg", "preload", "", "", "somevalue"}, On 2016/10/23 05:25:46, Mike West wrote: > I don't understand how this test works. You've added a `referrerPolicy` value, > but it doesn't look like you're checking it anywhere? And you haven't added the > value to any other item in the list? my bad. Forgot to add an actual check for the value :/
https://codereview.chromium.org/2424943002/diff/80001/third_party/WebKit/Sour... File third_party/WebKit/Source/core/html/parser/HTMLPreloadScanner.cpp (right): https://codereview.chromium.org/2424943002/diff/80001/third_party/WebKit/Sour... third_party/WebKit/Source/core/html/parser/HTMLPreloadScanner.cpp:363: SecurityPolicy::referrerPolicyFromStringWithLegacyKeywords( On 2016/10/23 13:27:09, Yoav Weiss wrote: > On 2016/10/23 05:25:46, Mike West wrote: > > Why do we accept legacy keywords on the `referrerpolicy` attribute? I thought > we > > only accepted those for `<meta>`? > > I just used whatever HTMLImageElement is using, and don't know the historical > events that brought said legacy mode upon us. > Scanning the code, it looks like the HTTP header and workers are not accepting > the legacy keywords, but the meta and attributes do accept it. > > estark is likely to have way more opinions on the matter than myself. Yeah, unfortunately all the attribute parsing is done with legacy keywords. I might be mis-remembering, but I think the code used to be set up such that we always parsed the legacy keywords for everything, and that's how the attributes shipped, and then we split up the code into legacy/non-legacy for the Referrer-Policy header. But since the attributes already shipped with legacy keywords, I think we at least have to measure usage before we remove support for them.
On 2016/10/23 14:27:04, estark wrote: > https://codereview.chromium.org/2424943002/diff/80001/third_party/WebKit/Sour... > File third_party/WebKit/Source/core/html/parser/HTMLPreloadScanner.cpp (right): > > https://codereview.chromium.org/2424943002/diff/80001/third_party/WebKit/Sour... > third_party/WebKit/Source/core/html/parser/HTMLPreloadScanner.cpp:363: > SecurityPolicy::referrerPolicyFromStringWithLegacyKeywords( > On 2016/10/23 13:27:09, Yoav Weiss wrote: > > On 2016/10/23 05:25:46, Mike West wrote: > > > Why do we accept legacy keywords on the `referrerpolicy` attribute? I > thought > > we > > > only accepted those for `<meta>`? > > > > I just used whatever HTMLImageElement is using, and don't know the historical > > events that brought said legacy mode upon us. > > Scanning the code, it looks like the HTTP header and workers are not accepting > > the legacy keywords, but the meta and attributes do accept it. > > > > estark is likely to have way more opinions on the matter than myself. > > Yeah, unfortunately all the attribute parsing is done with legacy keywords. I > might be mis-remembering, but I think the code used to be set up such that we > always parsed the legacy keywords for everything, and that's how the attributes > shipped, and then we split up the code into legacy/non-legacy for the > Referrer-Policy header. But since the attributes already shipped with legacy > keywords, I think we at least have to measure usage before we remove support for > them. In that light, what would be the best way to ship a new attribute? Usage for it is likely to be 0, but we're not likely to deprecate other attributes, shipping it in non-legacy mode is likely to be confuse developers. Or should we hold off shipping this until we have usage data?
On 2016/10/23 14:35:39, Yoav Weiss wrote: > On 2016/10/23 14:27:04, estark wrote: > > > https://codereview.chromium.org/2424943002/diff/80001/third_party/WebKit/Sour... > > File third_party/WebKit/Source/core/html/parser/HTMLPreloadScanner.cpp > (right): > > > > > https://codereview.chromium.org/2424943002/diff/80001/third_party/WebKit/Sour... > > third_party/WebKit/Source/core/html/parser/HTMLPreloadScanner.cpp:363: > > SecurityPolicy::referrerPolicyFromStringWithLegacyKeywords( > > On 2016/10/23 13:27:09, Yoav Weiss wrote: > > > On 2016/10/23 05:25:46, Mike West wrote: > > > > Why do we accept legacy keywords on the `referrerpolicy` attribute? I > > thought > > > we > > > > only accepted those for `<meta>`? > > > > > > I just used whatever HTMLImageElement is using, and don't know the > historical > > > events that brought said legacy mode upon us. > > > Scanning the code, it looks like the HTTP header and workers are not > accepting > > > the legacy keywords, but the meta and attributes do accept it. > > > > > > estark is likely to have way more opinions on the matter than myself. > > > > Yeah, unfortunately all the attribute parsing is done with legacy keywords. I > > might be mis-remembering, but I think the code used to be set up such that we > > always parsed the legacy keywords for everything, and that's how the > attributes > > shipped, and then we split up the code into legacy/non-legacy for the > > Referrer-Policy header. But since the attributes already shipped with legacy > > keywords, I think we at least have to measure usage before we remove support > for > > them. > > In that light, what would be the best way to ship a new attribute? Usage for it > is likely to be 0, but we're not likely to deprecate other attributes, shipping > it in non-legacy mode is likely to be confuse developers. > Or should we hold off shipping this until we have usage data? My vote would to land this without legacy keyword support, and separately deprecate/remove legacy keywords from the other attributes. AFAICT there is no documentation anywhere saying that legacy keywords are supported for attributes, so this shouldn't be too confusing for developers: I imagine that approximately no one will notice that they're supported for some elements but not for link. Mike, WDYT?
On 2016/10/23 at 19:42:39, estark wrote: > My vote would to land this without legacy keyword support, and separately deprecate/remove legacy keywords from the other attributes. AFAICT there is no documentation anywhere saying that legacy keywords are supported for attributes, so this shouldn't be too confusing for developers: I imagine that approximately no one will notice that they're supported for some elements but not for link. Mike, WDYT? SGTM. To summarize the rest: 1. I would like to see a spec at some point that shows folks what all of this is supposed to do. I agree with you that adding this kind of thing to the header is a reasonable analog to the `referrerpolicy` attribute on the element, but I can point to a document that defines the latter's behavior, and I can't do the same for the header, which makes it seriously unlikely that any other vendor will implement it. 2. The header's interaction with Fetch really needs to be defined somewhere. Can you commit to a plan to get things documented? I'd suggest that this piece of the patch probably needs more work (and tests, as our current behavior is unclear to me), but could be easily separated out into a second patch (and probably needs an intent to ship for visibility, if not originality). 3. Was there an intent to ship for the attribute? If so, I'd suggest pinging that thread, noting that `<link>` was missed and that it's being added in this patch. WDYT?
On 2016/10/24 10:52:08, Mike West wrote: > On 2016/10/23 at 19:42:39, estark wrote: > > My vote would to land this without legacy keyword support, and separately > deprecate/remove legacy keywords from the other attributes. AFAICT there is no > documentation anywhere saying that legacy keywords are supported for attributes, > so this shouldn't be too confusing for developers: I imagine that approximately > no one will notice that they're supported for some elements but not for link. > Mike, WDYT? > > SGTM. > > To summarize the rest: > > 1. I would like to see a spec at some point that shows folks what all of this is > supposed to do. I agree with you that adding this kind of thing to the header is > a reasonable analog to the `referrerpolicy` attribute on the element, but I can > point to a document that defines the latter's behavior, and I can't do the same > for the header, which makes it seriously unlikely that any other vendor will > implement it. > > 2. The header's interaction with Fetch really needs to be defined somewhere. Can > you commit to a plan to get things documented? I'd suggest that this piece of > the patch probably needs more work (and tests, as our current behavior is > unclear to me), but could be easily separated out into a second patch (and > probably needs an intent to ship for visibility, if not originality). > > 3. Was there an intent to ship for the attribute? If so, I'd suggest pinging > that thread, noting that `<link>` was missed and that it's being added in this > patch. > > WDYT? OK, I'll split up the header work to a separate patch, and open up related spec issues (both on referrerPolicy and Fetch). I can commit to pushing that along, but I'm afraid it'll take me a few weeks to dedicate some time to actually do the work. I'll also ping the intent to ship thread with current patch.
The CQ bit was checked by yoav@yoav.ws to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was checked by yoav@yoav.ws to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: Try jobs failed on following builders: linux_chromium_rel_ng on master.tryserver.chromium.linux (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)
The CQ bit was checked by yoav@yoav.ws to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: This issue passed the CQ dry run.
Patchset 8 LGTM after the intent to ship that Jochen asked for. Thanks!
will approve once the intent to ship is through. Please also add a link to the intent to the CL description. thx for working on this!
Description was changed from ========== Add ReferrerPolicy support to preload This CL adds referrerpolicy attribute support to link rel preload. BUG= 595099 ========== to ========== Add ReferrerPolicy support to preload This CL adds referrerpolicy attribute support to link rel preload. Intent to implement and ship: https://groups.google.com/a/chromium.org/d/msg/blink-dev/LukPJ86fcs8/RX_dsbUi... BUG= 595099 ==========
On 2016/10/26 08:24:35, jochen wrote: > will approve once the intent to ship is through. Please also add a link to the > intent to the CL description. > > thx for working on this! jochen - since you & others LGTMed the intent, are we good to go?
lgtm
On 2016/11/03 11:53:03, jochen wrote: > lgtm Thanks! :)
The CQ bit was checked by yoav@yoav.ws
The patchset sent to the CQ was uploaded after l-g-t-m from estark@chromium.org Link to the patchset: https://codereview.chromium.org/2424943002/#ps140001 (title: "Test fix")
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
Message was sent while issue was closed.
Description was changed from ========== Add ReferrerPolicy support to preload This CL adds referrerpolicy attribute support to link rel preload. Intent to implement and ship: https://groups.google.com/a/chromium.org/d/msg/blink-dev/LukPJ86fcs8/RX_dsbUi... BUG= 595099 ========== to ========== Add ReferrerPolicy support to preload This CL adds referrerpolicy attribute support to link rel preload. Intent to implement and ship: https://groups.google.com/a/chromium.org/d/msg/blink-dev/LukPJ86fcs8/RX_dsbUi... BUG= 595099 ==========
Message was sent while issue was closed.
Committed patchset #8 (id:140001)
Message was sent while issue was closed.
Description was changed from ========== Add ReferrerPolicy support to preload This CL adds referrerpolicy attribute support to link rel preload. Intent to implement and ship: https://groups.google.com/a/chromium.org/d/msg/blink-dev/LukPJ86fcs8/RX_dsbUi... BUG= 595099 ========== to ========== Add ReferrerPolicy support to preload This CL adds referrerpolicy attribute support to link rel preload. Intent to implement and ship: https://groups.google.com/a/chromium.org/d/msg/blink-dev/LukPJ86fcs8/RX_dsbUi... BUG= 595099 Committed: https://crrev.com/93f84740e06572bd05ca465067d7f98c24c4c514 Cr-Commit-Position: refs/heads/master@{#429567} ==========
Message was sent while issue was closed.
Patchset 8 (id:??) landed as https://crrev.com/93f84740e06572bd05ca465067d7f98c24c4c514 Cr-Commit-Position: refs/heads/master@{#429567} |
