Open sheganinans opened 6 years ago
Any luck on the replication of this bug? I tried it on a different installation of NixOS and got the same behavior.
Does the browser freeze with high CPU usage? That’s what I am observing here at least…
According to https://www.reddit.com/r/haskell/comments/88k18x/monthly_hask_anything_april_2018/dwm8qzr/ it is a Firefox-specific problem, and using Chrome avoids it.
I see this too, it’s a bummer because FF is my main browser. Any headway?
@3noch - you seem to have some insight into this bug. What exactly is the problem on FF?
Upping this issue, as I really care about not having to use Chrome to use JSaddle.
I took a look at this and minimized the example to https://github.com/niteria/jsaddle-repro
As expected it works in Chrome Version 81.0.4044.122 (Official Build) (64-bit) and fails on Firefox 77.0.1 (64-bit).
This is using the latest jsaddle
and jsaddle-warp
, version 0.9.7.0 for both.
Ok, this is really the same as https://github.com/ghcjs/jsaddle/issues/51. It fails in Firefox because Firefox completely disallows synchronous XHR requests. Chrome is less strict.
There's sync-xhr
that's supposed to allow this https://featurepolicy.info/policies/sync-xhr, but it's not implemented on Firefox.
So would the solution be only using async xhr?
Seems to be the same as https://github.com/ghcjs/jsaddle/issues/54 too maybe
Has progress been made towards this? I've been compiling to JS every time since seeing this issue - seeing as the default browser on deployments gets what looks like memory leaks.
I keep getting this error when using the jsaddle-warp backend. However the same exact reflex widget when using jsaddle-webkit2gtk will work perfectly fine.
To replicate this error:
Connect a web browser to http://localhost:3911, and click the button a few times and check the output in the cabal repl. Soon enough the error will show up and the webapp will freeze.
However if you instead run
cabal new-repl webkit-reflex
and try pushing the button, the app will work exactly as expected.