WebView2Feedback
WebView2Feedback copied to clipboard
MicrosoftEdge
[Problem/Bug]: Shopping causing 404, fetching React Like files
What happened?
What happened? Beginning May 2nd, Edge Internal Shopping Extension started to fetch some files from domains identified as shopping. Files do not exists and a lot of 404 are generated server side . This happen only in Edge not Chrome (No shopping feature).
i.e.: s.u = function(e) { return ({ 61: "lazy.commerceui-react.price-history", 179: "lazy.commerceui-react.theme", 190: "lazy.commerceui-wc-buying-options", 233: "lazy.commerceui-wc.themes", 255: "lazy.commerceui-react.price-activity", 507: "lazy.commerceui-wc.utils", 896: "lazy.commerceui-react.layout" }[e] || e) + ".js" }
Usually this do not cause problems, but in some legacy parts of sites, our application crashes.
Others are reporting issue on Reddit: https://www.reddit.com/r/MicrosoftEdge/comments/1cj8khj/ms_edge_124_hitting_our_server_looking_for/
Importance
Important. My app's user experience is significantly compromised.
Runtime Channel
Stable release (WebView2 Runtime)
Runtime Version
124.0.2478.51
SDK Version
No response
Framework
Win32
Operating System
Windows 10
OS Version
No response
Repro steps
- go to shopping website like Amazon.com
- In Dev Tools you can see the 404
Repros in Edge Browser
Yes, issue can be reproduced in the corresponding Edge version
Regression
No, this never worked
Last working version (if regression)
No response
We also see this behaviour happing in the last couple of days and it is creating the impression to our customers that it's our script that is producing errors and sideloading random scripts.
Experiencing same issues. milions requests per day, crazy. btw @nicolasbenoist what analytic tool are you using ? greylog/kibana ?
+1; I hope this gets resolved today. Huge impact on analytics.
+1. Millions of 404 requests to our servers related to this. Definitely not the best impression for our customers
Also noticed a massive increase of load on our servers trying to find these resources
+1 from RUMvision. It really started at May 2nd 7:30 UTC (but already a bit before as well). In our logs it stopped happening around May 3rd 9:03 UTC.
The weird + unexpected part is that we provide site owners with a JS snippet that dynamically embeds our (tracking) JS. And even that was somehow being (ab)used and called multiple times per second with different filenames:
/*/256.js
/*/273.js
/*/470.js
/*/763.js
/*/lazy.commerceui-react.layout.js
/*/lazy.commerceui-react.price-activity.js
/*/lazy.commerceui-react.price-history.js
/*/lazy.commerceui-react.theme.js
/*/lazy.commerceui-wc-buying-options.js
/*/lazy.commerceui-wc.themes.js
/*/lazy.commerceui-wc.utils.js
All these new requests resulted in bypassing our caching mechanism and hitting our main servers, causing quite a spike.
+1
Wondering if anyone else has also recently started seeing random 404's for HTTP POST requests to /[16-digit random characters]?
+1 this has a measurable impact when your resource provisioning is assuming almost everything is cached by a CDN...
+1. As a quick fix/workaround and to serve something for a CDN, you can create all those files with empty content, for example:
/lazy.commerceui-react.price-history.js
// Hello Edge :)
Hi all, thanks for the feedback. The issue has been fixed recently. Could you please validate from your side?
Additional info, you can check if the edge shopping component has been updated to Version: 2.0.6706.0.
- In Edge browser, go to edge://components.
- Check for update for Edge Shopping.
@Master-Ukulele Edge Shopping - Version: 2.0.6706.0 Is that the lastest Version with the patch?
Looks good at a first glance, could not provoke it manually. I will recheck the server logs in a few days if we still got any more requests.
Might take a day of two until it's gone for good until all edge components have updated properly.
@Master-Ukulele , I can confirm the component version 2.0.6706.0 by my side. Our backend Telemetry detected a strong reduction of 404 Beginning May 8th . Thanks a lot for this fix.