Able to reproduce this issue on reported version 64.0.3282.140, on latest beta 65.0.3325.51 and on latest canary 66.0.3345.0 using link given in comment#0. i.e; Canceled is seen instead of 404 in Network section of devtools.

Good Build: 64.0.3278.0
Bad Build: 64.0.3279.0

You are probably looking for a change made after 519280 (known good), but no later than 519281 (first known bad).
CHANGELOG URL:
 https://chromium.googlesource.com/chromium/src/+log/5e3ea73074e0d9c7455b3d8e40b938a7ace7231d..722937f7116a2c448d0700b6d90318852369c785

Suspecting same from changelog.

@ mkwst: This seems to be intended from changelog. Please have a look at the issue and help in re-assigning if it is not related to your change.

Adding RB-Stable for M-64. Please remove if not the case.

Thanks!

M65 Stable promotion is coming VERY soon. Your bug is labelled as Stable ReleaseBlock, pls make sure to land the fix and request a merge  into the release branch ASAP. Thank you.

Let's target this for M65. 

mkwst@,

Still seeing the same issue on stable,dev-66.0.3346.8,Beta-65.0.3325.73 & Canary-66.0.3350.0 on all OS.Could you please take a look into this issue as it is marked as M65 stable blocker.

Thanks..!

I wouldn't treat this as a stable blocker. It doesn't change the page's functionality, it just shows different text in the network panel's waterfall view.

In fact, the demo page serves CSS files as `text/html` and sends a `x-content-type-options: nosniff` header, so we do indeed error out the preload request. Do you see the same behavior if you serve the file as `text/css`, or leave off the `x-content-type-options` header? If not, I'd close this as WAI.

@mkwst,

I agree it's not a stable blocker - it's more an inconvenience. The example is an obvious one, but the reason I raised this is because in another page I made a typo and took me a bit to figure that out due to this bug! If it had shown 404 (or even allowed me to click on it to see the actual response) then I would have seen my error sooner.

>In fact, the demo page serves CSS files as `text/html`

That is incorrect! The demo page serves 404s as `text/html` - including 404s for stylesheets. Real stylesheets that DO exist are served as `text/css` (not shown on this simple demo site). This is fairly standard - I added an additional reference from www.google.com (404_html_google_preload.css) and it similarly returns `text/html` for a non-existent stylesheet (though isn't affected by this bug for reasons explained below). As I said this bug is only for 404s.

> Do you see the same behavior if you serve the file as `text/css`

No, this works if the stylesheet exists. It is only for 404s (which are served as `text/html` as they should be) that this is a problem.

> and sends a `x-content-type-options: nosniff` header, so we do indeed error out the preload request. Do you see the same behavior if you ... leave off the `x-content-type-options` header?

When I do turn of sending of `x-content-type-options: nosniff` headers it acts as expected. Also the Google 404 stylesheet preload that I added (404_html_google_preload.css) also works because it appears Google does not set this response header. However I WANT to have this header as it's a good security header to include (quote from https://developers.google.com/web/updates/2018/02/meltdown-spectre: "the Chrome team recommends adding the X-Content-Type-Options: nosniff header to all your responses.").

> If not, I'd close this as WAI.

Disagree - this is not Working As Intended. In fact I added a normal non-existent stylesheet reference (not preloaded) and it presents the same behaviour:

<link rel="stylesheet" type="text/css" media="all" href="/assets/css/404_not_preload.css">

So it's worse than I thought - it's not limited to preload. Maybe should be a stable blocker after all?

Interestingly when I add a <img src="non-existant-image.png"> it correctly shows the 404 response (despite being `text/html` and having `x-content-type-options: nosniff`). And similarly when I added a <script src="non-existent-javascript.js">. So looks like just stylesheets that this affects.

Thanks,
Barry

Normal 404 css file shows as "canceled" in the devTools, while the net-internals show's correctly as 404, although 404 for image file is correctly shown in the devTools.

Data reported by the network domain under the devTools protocol also exhibit the same behavior.

Deleted: Screen Shot 2018-06-15 at 11.07.50 AM.png 14.5 KB

	Screen Shot 2018-06-15 at 11.07.50 AM.png 14.5 KB View Download

Deleted: Screen Shot 2018-06-15 at 11.10.20 AM.png 256 KB

	Screen Shot 2018-06-15 at 11.10.20 AM.png 256 KB View Download

Deleted: Screen Shot 2018-06-15 at 11.12.12 AM.png 17.2 KB

	Screen Shot 2018-06-15 at 11.12.12 AM.png 17.2 KB View Download