#enable-experimental-web-platform-features breaks citi.com
Reported by
redneck....@gmail.com,
Sep 13
|
|||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/69.0.3497.92 Safari/537.36 Example URL: citi.com Steps to reproduce the problem: 1. Enable chrome://flags/#enable-experimental-web-platform-features 2. Log in to credit card account with citi (such as Costco Credit Card) 3. Site reports various errors indicating that things are broken on their end, account data not available at the moment. No account information shows. What is the expected behavior? The usual balances and such are expected to be shown. What went wrong? Save for it not working when this flag is enabled, I have no the slightest idea why. Does it occur on multiple sites: N/A Is it a problem with a plugin? No Did this work before? N/A Does this work in other browsers? Yes Chrome version: 69.0.3497.92 Channel: stable OS Version: 10.0 Flash Version: This is not a particularly important bug, but I figured it best I report it anyways.
,
Sep 20
I also hit this today. This breaks citi.com in Chrome but not Firefox or Edge. I do *not* have --enable-experimental-web-platform-features enabled. This is on Chrome 69.0.3497.95 beta, on ChromeOS 10895.56.0 (eve)
,
Sep 20
A look at devtools shows a number of 500's for XHR that look like they are for fetching account data. To reproduce you'll need a Citi-issued credit card to log in. I can maybe help bisect if I'm given specific instructions.
,
Sep 20
Hey mfoltz. I can't reproduce on my end (linux 69.0.3497.100) but here are instructions for how to bisect: https://www.chromium.org/developers/bisect-builds-py
,
Sep 20
A chrome://net-internals log would be useful here ( see https://www.chromium.org/for-testers/providing-network-details )
,
Sep 20
,
Sep 20
net-internals log shared to rsleevi@chromium.org
,
Sep 21
On the upside, nothing is appearing to be related to certificates, which had been suggested during triage. I do see a series of 500 errors and 403 errors for some XMLHttpRequests. Looking through some of the stuff, I note an "X-Backside-Transport: FAIL FAIL, FAIL FAIL" in some of the reports, which indicates it's an IBM server response. I seem to recall Mike having encountered some strange errors with certain servers and either cookie changes (was it strict?) or sec-metadata, but I could be entirely misremembering. mkwst@: Does any of this sound vaguely familiar?
,
Oct 17
Removing the network label - enable-experimental-web-platform-features doesn't actually have any effect on the network stack.
,
Oct 18
Perhaps https://bugs.chromium.org/p/chromium/issues/detail?id=861678? We've seen some web application firewalls explode when presented with the `Sec-Metadata` header in its initial form. Is that header present in the log, Ryan? If so, https://chromium-review.googlesource.com/c/chromium/src/+/1282603 might address it?
,
Oct 23
Pinging rsleevi re: #10. There are no XHR-specific features behind the #enable-experimental-web-platform-features flag. If there's an issue, it will be in loading.
,
Oct 23
I'm not sure #enable-experimental-web-platform-features is really the problem. I see this happening with #enable-experimental-web-platform-features turned on or off. It's been this way for ages for me on Canary, but not in any other Chrome release. I assume it must be a finch trial that I'm in. |
|||||||
►
Sign in to add a comment |
|||||||
Comment 1 by krajshree@chromium.org
, Sep 14