Address & payment dropdowns broke
3So apparently with Chrome 127, the dropdown to change address and/or payment methods no longer works, both on checkout pages and in account settings.
A console error message says: “[Deprecation] Listener added for a ‘DOMSubtreeModified’ mutation event. Support for this event type has been removed, and this event will no longer be fired. See https://chromestatus.com/feature/5083947249172480 for more information.”
For mercatalyst devs: looks like there’s a way to buy yourself a few months of reprieve here. The replacement’s technical details and migration instructions are here.
- 3 comments, 5 replies
- Comment
Odd. I’m on 127 and it’s functioning as intended. Looks a bit odd, but works. I’ll point the dev team this way and see if they’re able to replicate the error you’re seeing.
@ExtraMedium To be specific, for me, the dropdown itself opens but clicking on a different saved method (or “Add new payment setting”) doesn’t actually change anything.
Strangely enough, the suspicious console errors are no longer appearing for me, but it’s still not working… Sorry for pointing at the wrong thing. /shrug
Yikes! Thanks for the detailed bug report @AySz88. Including the console error message is very helpful.
Like @ExtraMedium I was also unable to replicate the error in my testing. I also did a full run of our automated tests using the latest version of Puppeteer (which uses Chrome for Testing 127.0.6533.88) and that didn’t fail any test cases.
I’ll keep trying different scenarios to see if I can replicate the issue. Wondering if there’s some environment difference that could be the root cause. Any notable Chrome extensions on your machine @AySz88?
@shawn I tried incognito mode to eliminate extensions as a factor, and the problem was still happening. I also tried both meh and sidedeal, and both checkout and the payment settings page on each. (Though, I don’t remember if I verified that the same console messages were there in all cases. But right now, the message is gone in all those, but the issue is still happening for me…)
I don’t know if there might be particular data in my account causing it? I do have six lines there, and I recently made an order that used a different card.
I can try with the #enable-benchmarking flags to see if maybe I’m in some Chrome field trial that has an issue…
Okay, some progress - I do get the issue with chrome://flags/#enable-benchmarking set to (“Match Field Trial Testing Config)”, and don’t get it when set to “(Default Feature States)”. So it looks like some field trial study is the issue.
Unfortunately I haven’t found a way to see which specific field trial(s) are active at any given time.
And thanks for the follow-ups @shawn.
Well I found some hex IDs (chrome://version) and deobfuscated parses in DevTools (x-client-data network headers sent to Google sites) but not a way to look the IDs up. This is what I have without #enable-benchmarking (when I do have the issue) in case you know a way:
@AySz88 Wow, this got way more interesting.
So we don’t directly use a ‘DOMSubtreeModified’ mutation event but this component is written using a slightly older version of React (v18.2) and maybe it does under the hood. But we’re also not sure if that’s the root cause once you’re in whatever field trial is causing this.
Thanks for your help. We’ll keep looking on our end.
@shawn I do remember seeing minified React code in the stack trace, but I no longer see the console errors when reproducing the issue, so I suspect that might have been a red herring. (Sorry!)
I did find that chrome://version/?show-variations-cmd generates a command line flag that supposedly turns on the same variations I have, but the thing it spat out is nearly 50KB long. (It does have test names instead of IDs, but it’s still a needle in haystack situation.) I put it in a pastebin: https://pastebin.com/DsQ5HSx7