zea@, if you're sure this is a regression, you may want to add Needs-Bisect label.

A netlog will be helpful here. Could you follow the instructions at https://sites.google.com/a/chromium.org/dev/for-testers/providing-network-details to grab a net-internals dump?

net-internals log attached

Deleted: net-internals-log.json 633 KB

net-internals-log.json 633 KB View Download

I don't see anything wrong from the net-log -- ERR_NAME_NOT_RESOLVED is being reported correctly. Removing Internals>Network label. Please re-attach if this needs network triager attention.

Right, the issue isn't that the error is being reported incorrectly, it's that the status code is being misreported. Perhaps this is an issue at a higher layer. Can you recommend a component that would own the status code reporting?

explicitly CC xunjieli@chromium.org to make sure they see the question in comment #5.  (Not sure if removing the Internals->Network label means they don't see updates to the bug anymore)

I tried chrome://sync-internals and see what you mean now. 
Does attachment_uploader_impl.cc handle the upload?
https://cs.chromium.org/chromium/src/components/sync/engine_impl/attachments/attachment_uploader_impl.cc?rcl=0&l=182 
If not, could you point me to the code that handles the upload?

The status code comes from SerializedNavigationEntry::ToSyncData, which just pulls it from the NavigationEntry.

Think the sync team is going to need to work back from the sync side of things, to figure out where the error is coming from.  Sync has a lot of hooks that make URLRequests, and it's not at all clear which is involved here, or even if that 200 is coming from a URLFetcher/URLRequest method, or is being made up by the sync code when it doesn't get any response headers, or what.

+ UI>Browser>Navigation

for content/browser/frame_host/navigation_entry_impl.cc

Oops, I missed comment #8.  If this is coming from the navigation, the issue is most likely in Blink or the navigation code.  We don't have any headers there, and the network stack does not provide a status code in this case (Or at least provides -1).

Sounds right. Thanks for helping triage!

Observations:

1. Tried to reproduce the issue on Mac OS 10.11.6 using chrome latest canary # M56 - 56.0.2895.0 and issue is reproduced. Followed steps given in comment #0.

2 . When tried to search for the keyword "pqwoeiruoewiuroewui" in "chrome://sync-internals/"no results found. (In all other chrome builds including M48).

Attached screenshots for reference.

Please let us know if we have followed correct steps to reproduce the issue and help us in triaging the issue better.

Thanks !

Deleted: 656845.mp4 690 KB

	656845.mp4 690 KB View Download

Deleted: 656845_1.mp4 279 KB

	656845_1.mp4 279 KB View Download

hdodda, could you try refreshing the pqwoeiruoewiuroewui.com page? Not sure why it's not reproing for you there (is tab sync enabled without encryption?). 

I managed to get test with some older builds, and it looks like this regressed in M46 (my M45 test showed a status code of 0).

One thing when manually testing is that if you're signing in to the same account on each build, you'll see the pages from other devices (including pqwoeiruoewiuroewui.com). You'll need to only look at the most recent instance of that page (you can check the timestamp).

Able to reproduce the issue on Windows 10, Mac 10.11.6 and Ubuntu 14.04 using latest canary #56.0.2896.0 

Bisect Information:
=====================
Good build: 46.0.2486.0
Bad Build : 46.0.2488.0

Change Log URL: 
https://chromium.googlesource.com/chromium/src/+log/531a47f1feff9429610f3a081c396eb3272cab10..cde6ab01bf44dec09247334deee11ea296c3aee2

Blink change logs:
https://chromium.googlesource.com/chromium/blink/+/63b8349e922a3691bb77f74d7b2f143a5f023626
https://chromium.googlesource.com/chromium/blink/+/feb3167bd8927debd1970e51da147772c68eadb7

From the change log unable to find the suspect. Could anyone from dev team please look into this issue.

Needs code investigation to be properly understood. 

Browser side: 
content::RenderFrameHostImpl::OnDidCommitProvisionalLoad() is invoked with IPC message FrameHostMsg_DidCommitProvisionalLoad_Params with http_status_code as 200.

Looking at the renderer side: 
content::RenderFrameImpl::SendDidCommitProvisionalLoad() does fill in 200 in the FrameHostMsg_DidCommitProvisionalLoad_Params. It is getting 200 from m_HttpStatusCode in ResourceResponse which is set when a copy is done between 2 WebURLResponses.
I do see blink::ResourceResponse::setHTTPStatusCode being invoked exactly once with 200 because of response.setHTTPStatusCode(200) being invoked in ResourceFetcher::resourceForStaticData while processing RenderFrameImpl::didFailProvisionalLoad() but its a different ResourceResponse object than the one being used in the WebURLResponse copy. Though, its possible that this ResourceResponse is being copied in some indirect way to the one being sent in the IPC message.

Can someone with blink code expertise see if this is indeed the root cause.
japhet@: do you think https://chromium.googlesource.com/chromium/blink/+/63b8349e922a3691bb77f74d7b2f143a5f023626 could be related?

cc to japhet@

japhet@, please see the earlier comment. Thanks.

Still seeing this issue on latest chrome version 56.0.2922.0.

Could any one from dev please look into this issue.

japhet@ is OOO.  mkwst@, it looks like you reviewed the CL in comment 20-- can you help triage this to see if that's involved?  If not, I may be able to look at it at some point, but I don't have time at the moment.

Any update here? There are several teams that are interested in getting this fixed.

@mkwst: Friendly Reminder, Could you please look on it.

Thank You!

Just to Update: Still able to reproduce the issue on Ubuntu 14.04 using latest chrome version 57.0.2969.0.

mkwst@ Could you please look into this issue.

Thanks!

Just to update, still able to reproduce this issue on Win-10 using latest canary #57.0.2976.0.

mkwst@ - Friendly Ping...!!

Could you please have a look into this issue.

Thanks...!!

Just to update, still able to reproduce this issue on mac 10.12.2 using latest canary #57.0.2983.0.

mkwst@ - Gentle Ping...!!

Could you please have a look into this issue.

Thanks...!!

Just to update, still able to reproduce this issue on mac 10.12.2 using latest canary #58.0.2990.0

mkwst@, Could you please take a look

I talked with Nate this morning, and I think he's tracked down the issue. I have a patch up to see if anything else has started to depend on the behavior that https://chromium.googlesource.com/chromium/blink/+/63b8349e922a3691bb77f74d7b2f143a5f023626 introduced, and should be able to get it landed relatively soon.

mkwst@, can you please provide a link to the patch under review?

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/1709b0599a7329585a3d781b21b1cbbb15379d7c

commit 1709b0599a7329585a3d781b21b1cbbb15379d7c
Author: mkwst <mkwst@chromium.org>
Date: Thu Mar 09 18:46:51 2017

Do not treat substitute-data resources as having successful HTTP status codes.

Some embedders of Blink (Chrome in particular) rely on error pages having an HTTP
status code of `0`. [1] changed this behavior to synthesize a 200 status code. This
patch changes that behavior back to the original expectation, matching the
expectation that non-network requests don't have network status information.

[1]: https://chromium.googlesource.com/chromium/blink/+/63b8349e922a3691bb77f74d7b2f143a5f023626

BUG= 656845 

Review-Url: https://codereview.chromium.org/2676443004
Cr-Commit-Position: refs/heads/master@{#455810}

[modify] https://crrev.com/1709b0599a7329585a3d781b21b1cbbb15379d7c/third_party/WebKit/LayoutTests/http/tests/security/XFrameOptions/x-frame-options-deny-expected.txt
[modify] https://crrev.com/1709b0599a7329585a3d781b21b1cbbb15379d7c/third_party/WebKit/LayoutTests/http/tests/security/XFrameOptions/x-frame-options-multiple-headers-conflict-expected.txt
[modify] https://crrev.com/1709b0599a7329585a3d781b21b1cbbb15379d7c/third_party/WebKit/Source/platform/loader/fetch/ResourceFetcher.cpp

Your change meets the bar and is auto-approved for M58. Please go ahead and merge the CL to branch 3029 manually. Please contact milestone owner if you have questions.
Owners: amineer@(clank), cmasso@(bling), bhthompson@(cros), govind@(desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Thanks for the fix, we will verify in latest canary and if all looks good, please merge to M58.

Please merge your change to M58 branch 3029 before 5:00 PM PT, Monday (03/13/17) so we can take it in for next week dev release. Thank you!

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/786e9d4707ec38cdb51eef38f6c635028e94b046

commit 786e9d4707ec38cdb51eef38f6c635028e94b046
Author: Mike West <mkwst@google.com>
Date: Mon Mar 13 07:50:56 2017

Do not treat substitute-data resources as having successful HTTP status codes.

Some embedders of Blink (Chrome in particular) rely on error pages having an HTTP
status code of `0`. [1] changed this behavior to synthesize a 200 status code. This
patch changes that behavior back to the original expectation, matching the
expectation that non-network requests don't have network status information.

[1]: https://chromium.googlesource.com/chromium/blink/+/63b8349e922a3691bb77f74d7b2f143a5f023626

BUG= 656845 

Review-Url: https://codereview.chromium.org/2676443004
Cr-Commit-Position: refs/heads/master@{#455810}
(cherry picked from commit 1709b0599a7329585a3d781b21b1cbbb15379d7c)

Review-Url: https://codereview.chromium.org/2750433002 .
Cr-Commit-Position: refs/branch-heads/3029@{#141}
Cr-Branched-From: 939b32ee5ba05c396eef3fd992822fcca9a2e262-refs/heads/master@{#454471}

[modify] https://crrev.com/786e9d4707ec38cdb51eef38f6c635028e94b046/third_party/WebKit/LayoutTests/http/tests/security/XFrameOptions/x-frame-options-deny-expected.txt
[modify] https://crrev.com/786e9d4707ec38cdb51eef38f6c635028e94b046/third_party/WebKit/LayoutTests/http/tests/security/XFrameOptions/x-frame-options-multiple-headers-conflict-expected.txt
[modify] https://crrev.com/786e9d4707ec38cdb51eef38f6c635028e94b046/third_party/WebKit/Source/platform/loader/fetch/ResourceFetcher.cpp

ligimole@: I've merged it back to make sure we're in the next release. If you find further issues, I'll fix and merge those too.