Improve console log message for CORS failure

Improve console log message for CORS failure

When a simple cross-origin request has been made and then blocked,
a log message of "blocked from loading" may sound confusing since we've
loaded the resource from the server but just prevented the response
from being delivered to the page.

When a redirect has been blocked, the error message should say that the
redirect has been blocked and the reason (e.g. whether the redirect location
is bad or the response didn't pass the CORS check) clearly.

BUG=417786
R=sof

Committed: https://crrev.com/e322d4d55b82f8bf1c4dd8e755e404bc46d9e39a
Cr-Commit-Position: refs/heads/master@{#408918}

[tyoshino (SeeGerritForStatus), 2015-06-24 13:17:46]

tyoshino@chromium.org changed reviewers:
+ sigbjornf@opera.com

[sof, 2015-06-25 11:24:18]

you're perhaps trying to do too many small things at the same time here.

https://chromiumcodereview.appspot.com/1196423003/diff/80001/LayoutTests/http...
File
LayoutTests/http/tests/xmlhttprequest/simple-cross-origin-denied-events-post-expected.txt
(right):

https://chromiumcodereview.appspot.com/1196423003/diff/80001/LayoutTests/http...
LayoutTests/http/tests/xmlhttprequest/simple-cross-origin-denied-events-post-expected.txt:1:
CONSOLE ERROR: XMLHttpRequest cannot load
http://localhost:8000/xmlhttprequest/resources/reply.xml. Response for preflight
doesn't pass the access control check: No 'Access-Control-Allow-Origin' header
is present on the requested resource. Origin 'http://127.0.0.1:8000' is
therefore not allowed access.
This strikes me as losing information. What if this is a multi-hop redirect, for
instance?

https://chromiumcodereview.appspot.com/1196423003/diff/80001/Source/core/fetc...
File Source/core/fetch/CrossOriginAccessControl.cpp (right):

https://chromiumcodereview.appspot.com/1196423003/diff/80001/Source/core/fetc...
Source/core/fetch/CrossOriginAccessControl.cpp:233: if
(!isLegalRedirectLocation(newURL, errorDescription))
This generated a console error message before containing the source origin, but
doesn't now. Wouldn't it be helpful to include that?

https://chromiumcodereview.appspot.com/1196423003/diff/80001/Source/core/fetc...
Source/core/fetch/CrossOriginAccessControl.cpp:254:
newRequest.setHTTPOrigin(securityOrigin->toAtomicString());
(This doesn't actually do what's intended, btw.)

https://chromiumcodereview.appspot.com/1196423003/diff/80001/Source/core/load...
File Source/core/loader/DocumentThreadableLoader.cpp (right):

https://chromiumcodereview.appspot.com/1196423003/diff/80001/Source/core/load...
Source/core/loader/DocumentThreadableLoader.cpp:466:
m_client->didFailAccessControlCheck(ResourceError(errorDomainBlinkInternal, 0,
response.url().string(), "Received response but it doesn't pass the access
control check: " + accessControlErrorDescription));
The prefixed text strikes me as redundant (and long) -- the error message makes
it implicitly clear that a response was received.

[tyoshino (SeeGerritForStatus), 2015-06-30 04:55:34]

On 2015/06/25 11:24:18, sof wrote:
> you're perhaps trying to do too many small things at the same time here.

Split variable renaming to https://codereview.chromium.org/1213343002/

[tyoshino (SeeGerritForStatus), 2015-06-30 05:30:08]

https://codereview.chromium.org/1196423003/diff/80001/Source/core/fetch/Cross...
File Source/core/fetch/CrossOriginAccessControl.cpp (right):

https://codereview.chromium.org/1196423003/diff/80001/Source/core/fetch/Cross...
Source/core/fetch/CrossOriginAccessControl.cpp:185: errorDescription = "Response
for preflight has invalid HTTP status code " +
String::number(response.httpStatusCode());
Split this change into https://codereview.chromium.org/1219693006/

[tyoshino (SeeGerritForStatus), 2016-07-22 12:44:09]

Patchset #6 (id:100001) has been deleted

[tyoshino (SeeGerritForStatus), 2016-07-22 12:46:17]

Description was changed from

==========
Improve console log message for CORS failure

When a simple cross-origin request has been made and then blocked,
a log message of "blocked from loading" may sound confusing since we've
loaded the resource from the server but just prevented the response
from being delivered to the page.

This CL also do some renaming for readability, and make some other CORS
related console log messages more consistent.

BUG=417786
==========

to

==========
Improve console log message for CORS failure

When a simple cross-origin request has been made and then blocked,
a log message of "blocked from loading" may sound confusing since we've
loaded the resource from the server but just prevented the response
from being delivered to the page.

When a redirect has been blocked, the error message should say that the
redirect has been blocked and the reason (e.g. whether the redirect location
is bad or the response didn't pass the CORS check) clearly.

BUG=417786
==========

[tyoshino (SeeGerritForStatus), 2016-07-22 12:46:45]

Reviving 13 month old CL...

https://codereview.chromium.org/1196423003/diff/80001/Source/core/fetch/Cross...
File Source/core/fetch/CrossOriginAccessControl.cpp (right):

https://codereview.chromium.org/1196423003/diff/80001/Source/core/fetch/Cross...
Source/core/fetch/CrossOriginAccessControl.cpp:233: if
(!isLegalRedirectLocation(newURL, errorDescription))
On 2015/06/25 11:24:18, sof wrote:
> This generated a console error message before containing the source origin,
but
> doesn't now. Wouldn't it be helpful to include that?

Good catch. Reverted.

https://codereview.chromium.org/1196423003/diff/80001/Source/core/loader/Docu...
File Source/core/loader/DocumentThreadableLoader.cpp (right):

https://codereview.chromium.org/1196423003/diff/80001/Source/core/loader/Docu...
Source/core/loader/DocumentThreadableLoader.cpp:466:
m_client->didFailAccessControlCheck(ResourceError(errorDomainBlinkInternal, 0,
response.url().string(), "Received response but it doesn't pass the access
control check: " + accessControlErrorDescription));
On 2015/06/25 11:24:18, sof wrote:
> The prefixed text strikes me as redundant (and long) -- the error message
makes
> it implicitly clear that a response was received.

OK. Removed

[sof, 2016-07-24 07:48:00]

https://codereview.chromium.org/1196423003/diff/120001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/fetch/CrossOriginAccessControl.cpp (right):

https://codereview.chromium.org/1196423003/diff/120001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/fetch/CrossOriginAccessControl.cpp:304:
errorMessage = "Redirect from '" + originalURL.getString() + "' has been blocked
because the redirect response does not pass CORS check: '" + errorDescription;
Would it be worth making the error message format be consistent with the above
(and ResourceFetcher's),

  "Redirect from <origin> has been blocked by CORS policy: <errorDescription>

?

https://codereview.chromium.org/1196423003/diff/120001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/fetch/CrossOriginAccessControl.cpp:311: if
(!originalOrigin->canRequest(newURL)) {
Some SecurityOrigin churn for this check, but i guess url security origins will
be cached.

https://codereview.chromium.org/1196423003/diff/120001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/loader/DocumentThreadableLoader.cpp (right):

https://codereview.chromium.org/1196423003/diff/120001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/loader/DocumentThreadableLoader.cpp:505: if
(m_corsRedirectLimit <= 0 || m_options.crossOriginRequestPolicy !=
UseAccessControl) {
nit: you could avoid the RHS if you conditionally initialize
m_corsRedirectLimit.

https://codereview.chromium.org/1196423003/diff/120001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/loader/DocumentThreadableLoader.cpp:532:
accessControlErrorDescription = "Redirect from '" +
redirectResponse.url().getString()+ "' to '" + request.url().getString() + "'
has been blocked because the redirect response does not pass CORS check: " +
accessControlErrorDescription;
Ditto re formatting.

[tyoshino (SeeGerritForStatus), 2016-07-26 09:13:00]

Thanks

https://codereview.chromium.org/1196423003/diff/120001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/fetch/CrossOriginAccessControl.cpp (right):

https://codereview.chromium.org/1196423003/diff/120001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/fetch/CrossOriginAccessControl.cpp:304:
errorMessage = "Redirect from '" + originalURL.getString() + "' has been blocked
because the redirect response does not pass CORS check: '" + errorDescription;
On 2016/07/24 07:48:00, sof wrote:
> Would it be worth making the error message format be consistent with the above
> (and ResourceFetcher's),
> 
>   "Redirect from <origin> has been blocked by CORS policy: <errorDescription>
> 
> ?

Good point. I initially changed this message to the following considering that
it might be good to clarify which of the redirect location or the redirect
response's CORS headers was bad.

"Redirect from <origin> has been blocked by CORS policy: Redirect response does
not pass CORS check: <errorDescription>"

And then, I noticed two CORS are redundant and consolidated the sentences.

I don't have strong opinion. Changed back to have better consistency.

https://codereview.chromium.org/1196423003/diff/120001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/fetch/CrossOriginAccessControl.cpp:311: if
(!originalOrigin->canRequest(newURL)) {
On 2016/07/24 07:48:00, sof wrote:
> Some SecurityOrigin churn for this check, but i guess url security origins
will
> be cached.

Could you please elaborate the comment? URL -> SecurityOrigin caching works only
for Blob URLs.

https://codereview.chromium.org/1196423003/diff/120001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/loader/DocumentThreadableLoader.cpp (right):

https://codereview.chromium.org/1196423003/diff/120001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/loader/DocumentThreadableLoader.cpp:505: if
(m_corsRedirectLimit <= 0 || m_options.crossOriginRequestPolicy !=
UseAccessControl) {
On 2016/07/24 07:48:00, sof wrote:
> nit: you could avoid the RHS if you conditionally initialize
> m_corsRedirectLimit.

Oh, I see! Done

https://codereview.chromium.org/1196423003/diff/120001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/loader/DocumentThreadableLoader.cpp:532:
accessControlErrorDescription = "Redirect from '" +
redirectResponse.url().getString()+ "' to '" + request.url().getString() + "'
has been blocked because the redirect response does not pass CORS check: " +
accessControlErrorDescription;
On 2016/07/24 07:48:00, sof wrote:
> Ditto re formatting.

Done.

[sof, 2016-07-27 11:51:03]

lgtm

https://codereview.chromium.org/1196423003/diff/120001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/fetch/CrossOriginAccessControl.cpp (right):

https://codereview.chromium.org/1196423003/diff/120001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/fetch/CrossOriginAccessControl.cpp:311: if
(!originalOrigin->canRequest(newURL)) {
On 2016/07/26 09:13:00, tyoshino wrote:
> On 2016/07/24 07:48:00, sof wrote:
> > Some SecurityOrigin churn for this check, but i guess url security origins
> will
> > be cached.
> 
> Could you please elaborate the comment? URL -> SecurityOrigin caching works
only
> for Blob URLs.

You're right, I thought some wider class of URLs were being cached for their
origins.

It is not an oft-used code path or anything, but having to allocate a pair of
temporary SecurityOrigins here, feels unsatisfactory - that's just what the
drive-by comment was trying to express. But it is how such checks are done.

https://codereview.chromium.org/1196423003/diff/140001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/fetch/CrossOriginAccessControl.cpp (right):

https://codereview.chromium.org/1196423003/diff/140001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/fetch/CrossOriginAccessControl.cpp:304:
errorMessage = "Redirect from '" + originalURL.getString() + "' has been blocked
by CORS policy: Redirect response does not pass CORS check: '" +
errorDescription;
I'll leave it up to you to make a final decision, but the "Redirect response
does not pass CORS check: " part is redundant and could be left out, imho.

https://codereview.chromium.org/1196423003/diff/140001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/loader/DocumentThreadableLoader.cpp (right):

https://codereview.chromium.org/1196423003/diff/140001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/loader/DocumentThreadableLoader.cpp:552:
RefPtr<SecurityOrigin> originalOrigin =
SecurityOrigin::create(redirectResponse.url());
Having complained a bit about RefPtr<SecurityOrigin> allocations.. :), let's
restructure this one a bit:

 if (!m_sameOriginRequest) {
     RefPtr<SecurityOrigin> originalOrigin = ...;
     RefPtr<SecurityOrigin> requestOrigin = ....;
     if (!originalOrigin->isSameSchemeHostPort(requestOrigin.get())) 
         ...
 }

[tyoshino (SeeGerritForStatus), 2016-07-28 12:23:06]

https://codereview.chromium.org/1196423003/diff/120001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/fetch/CrossOriginAccessControl.cpp (right):

https://codereview.chromium.org/1196423003/diff/120001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/fetch/CrossOriginAccessControl.cpp:311: if
(!originalOrigin->canRequest(newURL)) {
On 2016/07/27 11:51:03, sof wrote:
> On 2016/07/26 09:13:00, tyoshino wrote:
> > On 2016/07/24 07:48:00, sof wrote:
> > > Some SecurityOrigin churn for this check, but i guess url security origins
> > will
> > > be cached.
> > 
> > Could you please elaborate the comment? URL -> SecurityOrigin caching works
> only
> > for Blob URLs.
> 
> You're right, I thought some wider class of URLs were being cached for their
> origins.
> 
> It is not an oft-used code path or anything, but having to allocate a pair of
> temporary SecurityOrigins here, feels unsatisfactory - that's just what the
> drive-by comment was trying to express. But it is how such checks are done.

We could have a variant of canRequest() which takes a SecurityOrigin. It looks
canAccess() is not such a thing.

https://codereview.chromium.org/1196423003/diff/140001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/fetch/CrossOriginAccessControl.cpp (right):

https://codereview.chromium.org/1196423003/diff/140001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/fetch/CrossOriginAccessControl.cpp:304:
errorMessage = "Redirect from '" + originalURL.getString() + "' has been blocked
by CORS policy: Redirect response does not pass CORS check: '" +
errorDescription;
On 2016/07/27 11:51:03, sof wrote:
> I'll leave it up to you to make a final decision, but the "Redirect response
> does not pass CORS check: " part is redundant and could be left out, imho.

Hmm, ok. Removed.

https://codereview.chromium.org/1196423003/diff/140001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/loader/DocumentThreadableLoader.cpp (right):

https://codereview.chromium.org/1196423003/diff/140001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/loader/DocumentThreadableLoader.cpp:552:
RefPtr<SecurityOrigin> originalOrigin =
SecurityOrigin::create(redirectResponse.url());
On 2016/07/27 11:51:03, sof wrote:
> Having complained a bit about RefPtr<SecurityOrigin> allocations.. :), let's
> restructure this one a bit:
> 
>  if (!m_sameOriginRequest) {
>      RefPtr<SecurityOrigin> originalOrigin = ...;
>      RefPtr<SecurityOrigin> requestOrigin = ....;
>      if (!originalOrigin->isSameSchemeHostPort(requestOrigin.get())) 
>          ...
>  }

Oh, nice :)

[tyoshino (SeeGerritForStatus), 2016-07-28 12:42:45]

Description was changed from

==========
Improve console log message for CORS failure

When a simple cross-origin request has been made and then blocked,
a log message of "blocked from loading" may sound confusing since we've
loaded the resource from the server but just prevented the response
from being delivered to the page.

When a redirect has been blocked, the error message should say that the
redirect has been blocked and the reason (e.g. whether the redirect location
is bad or the response didn't pass the CORS check) clearly.

BUG=417786
==========

to

==========
Improve console log message for CORS failure

When a simple cross-origin request has been made and then blocked,
a log message of "blocked from loading" may sound confusing since we've
loaded the resource from the server but just prevented the response
from being delivered to the page.

When a redirect has been blocked, the error message should say that the
redirect has been blocked and the reason (e.g. whether the redirect location
is bad or the response didn't pass the CORS check) clearly.

BUG=417786
R=sof
==========

[tyoshino (SeeGerritForStatus), 2016-07-28 12:42:53]

The CQ bit was checked by tyoshino@chromium.org

[tyoshino (SeeGerritForStatus), 2016-07-28 12:42:53]

The patchset sent to the CQ was uploaded after l-g-t-m from sigbjornf@opera.com
Link to the patchset: https://codereview.chromium.org/1196423003/#ps160001
(title: "Addressed #12")

[commit-bot: I haz the power, 2016-07-28 12:43:08]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-07-28 13:49:11]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-07-28 13:49:12]

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_...)

[tyoshino (SeeGerritForStatus), 2016-07-29 12:19:57]

The CQ bit was checked by tyoshino@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-07-29 12:20:07]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-07-29 13:43:12]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-07-29 13:43:14]

Dry run: This issue passed the CQ dry run.

[tyoshino (SeeGerritForStatus), 2016-08-01 04:10:50]

Updated more test expectations I didn't cover.

[tyoshino (SeeGerritForStatus), 2016-08-01 04:10:57]

The CQ bit was checked by tyoshino@chromium.org

[tyoshino (SeeGerritForStatus), 2016-08-01 04:10:58]

The patchset sent to the CQ was uploaded after l-g-t-m from sigbjornf@opera.com
Link to the patchset: https://codereview.chromium.org/1196423003/#ps260001
(title: "Reverted from change")

[commit-bot: I haz the power, 2016-08-01 04:11:12]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-08-01 04:14:06]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-08-01 04:14:07]

Try jobs failed on following builders:
  cast_shell_linux on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/cast_shell_linu...)
  chromium_presubmit on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/chromium_presub...)
  linux_chromium_asan_rel_ng on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)
  linux_chromium_clobber_rel_ng on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)
  linux_chromium_compile_dbg_ng on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)
  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_...)

[tyoshino (SeeGerritForStatus), 2016-08-01 04:36:42]

The CQ bit was checked by tyoshino@chromium.org

[tyoshino (SeeGerritForStatus), 2016-08-01 04:36:43]

The patchset sent to the CQ was uploaded after l-g-t-m from sigbjornf@opera.com
Link to the patchset: https://codereview.chromium.org/1196423003/#ps280001
(title: "Rebase")

[commit-bot: I haz the power, 2016-08-01 04:36:55]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-08-01 04:44:23]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-08-01 04:44:24]

Try jobs failed on following builders:
  cast_shell_linux on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/cast_shell_linu...)
  mac_chromium_rel_ng on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_...)

[tyoshino (SeeGerritForStatus), 2016-08-01 04:54:07]

The CQ bit was checked by tyoshino@chromium.org

[tyoshino (SeeGerritForStatus), 2016-08-01 04:54:08]

The patchset sent to the CQ was uploaded after l-g-t-m from sigbjornf@opera.com
Link to the patchset: https://codereview.chromium.org/1196423003/#ps300001
(title: "Fix")

[commit-bot: I haz the power, 2016-08-01 04:54:15]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-08-01 06:19:15]

Description was changed from

==========
Improve console log message for CORS failure

When a simple cross-origin request has been made and then blocked,
a log message of "blocked from loading" may sound confusing since we've
loaded the resource from the server but just prevented the response
from being delivered to the page.

When a redirect has been blocked, the error message should say that the
redirect has been blocked and the reason (e.g. whether the redirect location
is bad or the response didn't pass the CORS check) clearly.

BUG=417786
R=sof
==========

to

==========
Improve console log message for CORS failure

When a simple cross-origin request has been made and then blocked,
a log message of "blocked from loading" may sound confusing since we've
loaded the resource from the server but just prevented the response
from being delivered to the page.

When a redirect has been blocked, the error message should say that the
redirect has been blocked and the reason (e.g. whether the redirect location
is bad or the response didn't pass the CORS check) clearly.

BUG=417786
R=sof
==========

[commit-bot: I haz the power, 2016-08-01 06:19:17]

Committed patchset #15 (id:300001)

[commit-bot: I haz the power, 2016-08-01 06:20:43]

Description was changed from

==========
Improve console log message for CORS failure

When a simple cross-origin request has been made and then blocked,
a log message of "blocked from loading" may sound confusing since we've
loaded the resource from the server but just prevented the response
from being delivered to the page.

When a redirect has been blocked, the error message should say that the
redirect has been blocked and the reason (e.g. whether the redirect location
is bad or the response didn't pass the CORS check) clearly.

BUG=417786
R=sof
==========

to

==========
Improve console log message for CORS failure

When a simple cross-origin request has been made and then blocked,
a log message of "blocked from loading" may sound confusing since we've
loaded the resource from the server but just prevented the response
from being delivered to the page.

When a redirect has been blocked, the error message should say that the
redirect has been blocked and the reason (e.g. whether the redirect location
is bad or the response didn't pass the CORS check) clearly.

BUG=417786
R=sof

Committed: https://crrev.com/e322d4d55b82f8bf1c4dd8e755e404bc46d9e39a
Cr-Commit-Position: refs/heads/master@{#408918}
==========

[commit-bot: I haz the power, 2016-08-01 06:20:45]

Patchset 15 (id:??) landed as
https://crrev.com/e322d4d55b82f8bf1c4dd8e755e404bc46d9e39a
Cr-Commit-Position: refs/heads/master@{#408918}