inputElement triggers hang with continuous xhr requests

Question

inputElement triggers hang with continuous xhr requests

maralorn opened this issue 5 years ago · comments

I have a freshly created project with ob init.

I changed the frontend variable in frontend/src/Frontend.hs to the following.

frontend :: Frontend (R FrontendRoute)
frontend =
  Frontend
    { _frontend_head = el "title" $ text "My Obelisk Example"
    , _frontend_body = el "div" $ void $ inputElement def
    }

No I run ob run and go to http://localhost:8000. When I click into the the inputElement my firefox runs wild with repeating requests like this:

Request URL:http://127.0.0.1:8000/jsaddle/sync/-3886772229270879785
Request method:POST
Remote address:127.0.0.1:8000
Status code: 200

Payload: {"tag":"BatchResults","contents":[43,{"tag":"Success","contents":[[],[]]}]}
Response Payload: [[{"Left":{"tag":"FreeRefs","contents":"ThreadId 18582"}}],false,43]

I would expect nothing to happen. Any insights into what is going on here would be highly appreciated.

cgibbard · Answer 1 · Mon Jun 24 2019 06:29:26 GMT+0800 (China Standard Time)

Which browser and platform? This jsaddle behaviour seems to happen for at least some people (if not everyone) on Firefox. I'm not entirely certain what causes it, but it only seems to happen with ob run and doesn't happen with the ghcjs frontend. Personally, I just use Chrome for ob run, even though I typically use Firefox for most things. It would be nice to sort out why this is happening.

tshinohara · Answer 2 · Mon Jun 24 2019 11:41:15 GMT+0800 (China Standard Time)

My understanding is that this behaviour is expected since ob run uses jsaddle-warp to run most of code on ghc side, and communicates with the browser for dom effects.
Though I haven't look into the code so I not sure if its jsaddle-warp or something else.

cgibbard · Answer 3 · Mon Jun 24 2019 11:53:26 GMT+0800 (China Standard Time)

It certainly should be communicating with jsaddle, perhaps even quite a bit, depending on the user input you're providing. It should not be unresponsive and thrashing.
Using ob run, your frontend is running in ghci as native code / interpreted bytecode, not being compiled to JavaScript. It communicates a bunch with the running browser via that websocket to obtain information about what events are taking place and to obtain values only the browser could know, as well as sending commands to control what is happening in the DOM.

tshinohara · Answer 4 · Mon Jun 24 2019 14:22:14 GMT+0800 (China Standard Time)

@cgibbard So that's how it was. Thank's for your explaination.

maralorn · Answer 5 · Mon Jun 24 2019 16:29:15 GMT+0800 (China Standard Time)

Oooh, that's interesting. All the black magic obelisk is doing would be much nicer, if I’d know about it.^^

I’m running Firefox 67.0.4 (64-bit) on nixos-19.03.

So is there a way to use ob run with the ghcjs version?

Tom Smalley · Answer 6 · Mon Jun 24 2019 18:54:22 GMT+0800 (China Standard Time)

There is no support for using ghcjs(i) with ob run. Unfortunately we are limited to using some variant of chromium for development, here is a related issue: ghcjs/jsaddle#64

Jonas Schürmann · Answer 7 · Wed Aug 21 2019 01:34:22 GMT+0800 (China Standard Time)

I'm having the same issue in Firefox, it works in Chromium.

blargg · Answer 8 · Tue Nov 19 2019 06:46:58 GMT+0800 (China Standard Time)

I think it would be good to warn about this when we tell people how to develop using ob run. I made a PR for this #554.

Dan Dart · Answer 9 · Sat Mar 06 2021 03:20:10 GMT+0800 (China Standard Time)

Is this not because it's synchronous?

madeline-os · Answer 10 · Sat May 21 2022 09:45:17 GMT+0800 (China Standard Time)

We have a note about this in the README and I am adding a section to the FAQ in #927, as it is easy to miss. Beyond that, all I can do is attempt to push effort in the direction of fixing the issue upstream.