I confirm. Thanks for communicating this. PRs to explain this to users are welcome.

Also I got access to the document they mention in a comment. Unfortnately their plan is to remove it (in M86) without a replacement. But they want to collect user feedback before doing that. Personally, I don't think we can persuade them to keep the feature in current form. CLJS is pretty small community. We have to hope that some other bigger players rely on this and will throw in their weight.

Just to add. I think users have to re-enable this feature every time they open the devtools. When they close it, the devtools instance goes away and the setting will be reset next time they open it.

So for a scenario where you have a development session where you keep your devtools opened since starting Chrome you have to do it once per development session which is not that bad IMO.

Stumbled upon this today. I was really confused as to why my custom formatter was broken, then I realized the setting automatically disables itself now. Once this feature is removed, cljs-devtools will no longer be usable. Are there any ideas on a replacement / solution for the future?

One option is to use Dirac, where I reverted the change for now:
binaryage/dirac@4d321af

btw. If you are using macOS, Dirac is not such pain to setup anymore - with the new CLI workflow:
https://github.com/binaryage/dirac

Hadn't heard of dirac, thanks for sharing! Going to check out

Has anyone looked if it's possible to get custom formatters to work in Firefox instead?

Has anyone looked if it's possible to get custom formatters to work in Firefox instead?

I briefly spoke with @codehag about this last year. I think in principle it would be doable, but it would require a lot of work from someone, and it likely wasn’t a high priority for Mozilla to do themselves. I’m not sure how the calculus on accepting this would change if Google is removing it from Chrome. The spec just being a Google doc is also a problem. There is an open bug for this already: https://bugzilla.mozilla.org/show_bug.cgi?id=1262914

Ah, at least it hasn't been rejected.

It's been put on hold now, after receiving user feedback. So hope is still there.

https://twitter.com/ChromeDevTools/status/1263428187809251328

Document linked above also includes "This has been put on hold due to user feedback"

I'm the engineer behind this change. I'd like to give some background.

You will have noticed that the intended removal was planned to be rolled out step by step. The first step being that the experimental setting no longer sticks, and has to be enabled for every DevTools session. We intentionally did not remove the feature at once. It also has not yet rolled out in Chrome's stable channel. Feedback like the one provided here is what we have been looking for, so thank you for that.

As for the rationale for the original proposal: custom formatters are an experimental feature and also not part of any spec, so we were not sure whether it found any significant adoption. Unfortunately, it has a flawed design, which made it a part of several security exploits in the past.

I can see that custom formatters are being relied on. That's why I already reverted the first step. We will reconsider this issue and hopefully can come up with a solution that doesn't break your use case.

Thank you very much, @hashseed. I'm ready to promptly rewrite/adapt cljs-devtools for the new solution. Whatever you come up with.

Assuming "a better and safer JSON-ML", I'd suggest to implement the new renderer/subsystem as a separate open-source library decoupled from devtools codebase. This would greatly help porting this functionality to other browsers and to "in-page space". We already have some projects[1][2] which had to reimplement JSON-ML rendering in other contexts because they wanted to reuse cljs-devtools functionality. Other people were interested rendering custom formatters in their own debug tools in-page. Not sure how much effort are you going to spend on it, but this portability would be something to consider.

[1] https://github.com/day8/re-frame-10x
[2] https://github.com/day8/re-frame-10x/blob/8aef576e31277fe15676558eb3841201b815f5cf/src/day8/re_frame_10x/view/components.cljs#L127

Should the changes made in 1.0.1 be reverted now?

@TimvdLippe yes, they will be reverted with explanation.

I just released v1.0.2 which has the warning removed.

We can still see some reports from people having Chrome version with non-sticky custom formatters and who missed the warning and release notes. So I will leave this issue open for a while.

The non-sticky setting is already being rolled out with Canary. But it still needs to be cherry-picked into Chrome 84. Will do this next week.