Any updates on this defect? We are looking for the Chromium team to confirm our assumption that this is a Chromium issue and not an application issue.

This is a pretty critical issue for our application. We are looking for someone from Chromium to help provide direction. If you need any more details, please let us know. 

Tried to reproduce the issue on latest chrome stable 68.0.3440.106 using Mac 10.13.6. Attaching screen-cast for reference.
Steps: 
------
1. Launched reported chrome 
2. Navigated the URL " https://myjohndeere.tal.deere.com " 
3. Tried to create a user 
As we are getting error while creating a user as per screen-cast

@Reporter: Could you please review the attached screen-cast and confirm if anything being missed here.Could you please upgrade to latest chrome Beta 69.0.3497.57, you can download latest chrome builds here:" https://www.chromium.org/getting-involved/dev-channel ". Chrome beta is rolled out very soon as stable. Let us know whether issue still persists.
Thanks.!

Deleted: 871998.mp4 1.2 MB

	871998.mp4 1.2 MB View Download

Hi, looks like it was temporary issue with our development environment. We used the email in screen cast and could register successfully. You should have an email in your inbox with a link to validate your profile.

Thank you for providing more feedback. Adding the requester to the cc list.

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

Thanks for registering using the email ID shown in screencast, we have successfully validated our profile and have set the password.
After navigating to https://def-chrome.devl.us.e01.c01.johndeerecloud.com/ and Zoomed In/Out when tiles are loaded (...into aqua colour), we didn't observe any 403s in DevTools console.

@Reporter: As mentioned in comment#0 about being connected with a server, Could you please mention if it's mandatory to connect to a server in order to reproduce this issue. Requesting you to check the same issue on the latest chrome stable and let us know its behaviour, as version 66.0.3359.181 being an old one. Please find the below URL to download/install the chrome latest versions.
https://www.chromium.org/getting-involved/dev-channel

Thanks!

I was able to reproduce this with: Version 69.0.3497.81 (Official Build) (64-bit) on Mac. 

Please make sure your repeatedly click the zoom out and/or zoom in button without hesitation. I was able to make it occur on the first try for a 3 or 4 times I attempted. 

Hi, We tested the issue in latest stable version and could reproduce it easily. The steps were very similar to the gif provided in comment#0. Can you please try again?

As cookies are lost during subsequent requests, server interaction would be required.

Latest stable version tried: Version 69.0.3497.81 (Official Build) (64-bit)

Thank you for providing more feedback. Adding the requester to the cc list.

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

As per comment#9, the issue seems to be triaged with server interaction which would be out of scope for us to triage it further from our end, hence requesting someone from Internals>Network>Cookies team to have a look into it and help in further triaging it.

Thanks!

Adding label "TE-NeedsTriageHelp" and requesting someone from Internals>Network>Cookies team to help in further triaging it.

Thanks!

Hi Team, Any update on this? Please let us know if you have any questions.

I was able to reproduce this issue.

Can you reproduce it without opening devtools? It might be related to the SameSite=Lax attribute when the request is initiated by devtools instead of the site.

This seems likely to be an issue with chrome-devtools://devtools/ URLs appearing in the initiator field.

Talked a bit more to chlily about this.  We're pretty confident this is solely a devtools issue, due to it misconfiguring its ResourceRequests' |request_initiator| field, which is used for the SameSite=Lax check.

We defer to the devtools team (and maybe the loader team) on fixing it - the network stack team doesn't have much familiarity with the code in blink to issue requests, or how that changes when devtools is enabled.

Thanks, we too couldn't reproduce this with the devtools closed.

Thank you for providing more feedback. Adding the requester to the cc list.

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

Great, thanks for the prompt follow up, and sorry for the delay investigating!

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

commit 75e890c93616d0eca19c8aa67fec2133bcf7756e
Author: Joey Arhar <jarhar@chromium.org>
Date: Tue Oct 16 19:57:53 2018

[DevTools] Don't show image preview on failed requests

Bug:  871998 
Change-Id: I7b1f69418ccae1d8e8edc867f7264d571b3986b3
Reviewed-on: https://chromium-review.googlesource.com/c/1277246
Commit-Queue: Joey Arhar <jarhar@chromium.org>
Reviewed-by: Dmitry Gozman <dgozman@chromium.org>
Cr-Commit-Position: refs/heads/master@{#600091}
[add] https://crrev.com/75e890c93616d0eca19c8aa67fec2133bcf7756e/third_party/WebKit/LayoutTests/http/tests/devtools/network/failed-request-preview-expected.txt
[add] https://crrev.com/75e890c93616d0eca19c8aa67fec2133bcf7756e/third_party/WebKit/LayoutTests/http/tests/devtools/network/failed-request-preview.js
[modify] https://crrev.com/75e890c93616d0eca19c8aa67fec2133bcf7756e/third_party/blink/renderer/devtools/front_end/sdk/NetworkRequest.js

Thanks for your investigation mmenke@ and chlily@

The problem is that the network panel in DevTools re-issues failed requests for images in order to create an image preview. In this case, the request didn't contain authentication and would get redirected and somehow change the cookie. I couldn't see how or where the cookie was getting changed, but I changed the network panel to stop issuing those requests which fixed the bug.

 Issue 895939  has been merged into this issue.

The cookie was presumably changed by the server, which was confused by DevTools requests losing their cookies, so to speak.  Thanks for the investigation!