These are chat archives for canjs/canjs

30th
Nov 2018
RyanMilligan
@RyanMilligan
Nov 30 2018 20:49
Has anyone else noticed that every network request made from can-ajax is synchronous? I edited can-ajax.js (https://github.com/canjs/can-ajax/blob/d5241b027ac2b44ec83e7014c89db2eccda72af6/can-ajax.js#L217) to pass true as the third parameter to xhr.open(), and that seems to have solved the issue. Is there a reason the framework isn't doing this by default?
RyanMilligan
@RyanMilligan
Nov 30 2018 21:06
Huh, but in Production our requests appear to be asynchronous, using the same version of can-ajax.
Frank Lemanschik
@frank-dspeed
Nov 30 2018 21:49
@RyanMilligan i think your looking wrong :)
and you don't see the diffrence between async and sync requests
RyanMilligan
@RyanMilligan
Nov 30 2018 21:49
What I know is that our UI is locking up when a network call is being run, and when I edit can-ajax.js to pass true as the third parameter to xhr.open(), the UI stops locking up.
Frank Lemanschik
@frank-dspeed
Nov 30 2018 21:50
what means UI Lockup
whats the code for that
RyanMilligan
@RyanMilligan
Nov 30 2018 21:50
It means you can't scroll, the cursor doesn't change when you mouse over buttons...the UI is blocked by the network call.
Frank Lemanschik
@frank-dspeed
Nov 30 2018 21:51
This sounds not logical to me
RyanMilligan
@RyanMilligan
Nov 30 2018 21:51
If I hit the break button in the Chrome debugger, it also waits until the network call finishes, then breaks on the first line of the readystatechanged event handler in can-ajax.js.
Frank Lemanschik
@frank-dspeed
Nov 30 2018 21:51
i think something else is also wrong
your talking about blocking code
but that don't means that it is sync or async
for example a promise is always async
RyanMilligan
@RyanMilligan
Nov 30 2018 21:52
The send call doesn't return until after the network call finishes. That's the definition of a synchronous network call.
Frank Lemanschik
@frank-dspeed
Nov 30 2018 21:52
no matter if you run code that runs a syncron function
if you can demonstrate that in a minimal codepen
your welcome i will look into it
use that as starting point
and add to the import also ajax
thats can-ajax
RyanMilligan
@RyanMilligan
Nov 30 2018 21:54
Hang on, let me add some logging around it to double check that this is what's happening.
Frank Lemanschik
@frank-dspeed
Nov 30 2018 21:55
simply issulate the problem
code a example that shows the problem
if it don't happens in the example
something else is wrong
Frank Lemanschik
@frank-dspeed
Nov 30 2018 22:01
import { Component, ajax } from "//unpkg.com/can@5/core.mjs";
one thing that can cause a so called UI Lock is that u use can-ajax to get a value from a resource that don't fails right
and so the whole component don't renders
to solve that you need to add error handling
RyanMilligan
@RyanMilligan
Nov 30 2018 22:03
It renders fine, once the network call finishes.
The UI is just unresponsive for the time that the call is running. It's definitely a synchronous network call, I'm just not sure why.
Frank Lemanschik
@frank-dspeed
Nov 30 2018 22:04
then this looks for me more like a design fail
can you post that component?
the js code
RyanMilligan
@RyanMilligan
Nov 30 2018 22:04
I do have a wrapper around XMLHttpRequest.prototype.open that accepts all the same parameters, adds a listener to handle some standard error handling, and then calls the regular open and passes all the arguments.
Frank Lemanschik
@frank-dspeed
Nov 30 2018 22:04
this sounds not so good for me
RyanMilligan
@RyanMilligan
Nov 30 2018 22:05
I don't know why you're focusing on the component. This happens for EVERY network call our application makes, and is completely fixed when I hard-code true as the third parameter to xhr.open().
Frank Lemanschik
@frank-dspeed
Nov 30 2018 22:05
i mean if you start listen you need to stop listen and all that
i say that because i am familar with such issues
and they get fixed in the component
the component renders once the viewModel is finished
so if you have defined the viewModel with wrong patterns
the result is exactly what you call UI Locked
Kevin Phillips
@phillipskevin
Nov 30 2018 22:06
@RyanMilligan XHR defaults to async
RyanMilligan
@RyanMilligan
Nov 30 2018 22:07
@phillipskevin The docs say it does, but again, adding true as the third parameter solved the problem. That's why I don't think it has anything to do with any components.
Kevin Phillips
@phillipskevin
Nov 30 2018 22:07
is it only happening for a specific browser?
RyanMilligan
@RyanMilligan
Nov 30 2018 22:08
We've only tried it in Chrome, I've just asked my co-worker to try it in Firefox.
@frank-dspeed If any of that were the issue, it wouldn't be solved by passing true to xhr.open().
It's not happening in Firefox, only Chrome.
Kevin Phillips
@phillipskevin
Nov 30 2018 22:11
ok, can you open an issue?
we can test it and set the async param explicitly
RyanMilligan
@RyanMilligan
Nov 30 2018 22:12
Yes, I can do that. I don't know exactly under what circumstances it happens, but there really doesn't seem any harm in just passing true for async.
The good news is that I can also just hard-code it in my open wrapper, so we have a work-around.
Kevin Phillips
@phillipskevin
Nov 30 2018 22:13
does your wrapper ever get called with 3 params?
RyanMilligan
@RyanMilligan
Nov 30 2018 22:14
Not from you guys. There is another mechanism that sometimes calls open (this is kind of a franken-app with a newly-written Can component embedded inside of a legacy Backbone\JQuery application), but it's passing true for async.
Frank Lemanschik
@frank-dspeed
Nov 30 2018 22:15
hehehehe
i was sure its something like FrankenApp
because i am frank and i coded stuff that exactly acts UI Locking :)
but not ajax related
simple never ending network calls
i am sure a pure canjs component with can-ajax will not block while doing requests as long as your using promises
even in chrome
RyanMilligan
@RyanMilligan
Nov 30 2018 22:17
Yeah, that was my first suspicion, but again...if that were the problem, passing true wouldn't fix it. And also it would do basically the same thing in other browsers.
Frank Lemanschik
@frank-dspeed
Nov 30 2018 22:17
sure true would fix it
setTimeout would also fix it
wrapping the result of the property into a promise would solve it also
i could look what true really does
and it will be something like that
RyanMilligan
@RyanMilligan
Nov 30 2018 22:18
I'm sorry, but your argument doesn't seem like it makes any sense here. It's using can-ajax, obviously it's using promises. But the call to open isn't returning until after the network call is done.
So you call open, the entire network call runs and the response is received, then the function returns the promise, which has already been resolved at that point. It's not possible for an application to stay responsive during the network call in that scenario, no matter what component framework you're using.
Frank Lemanschik
@frank-dspeed
Nov 30 2018 22:19
try returning a value befor it is resolved
like myResult: Promise.resolve('EMPTY')
RyanMilligan
@RyanMilligan
Nov 30 2018 22:19
The open call literally doesn't return until after the network call has happened. This is all in can-ajax.js.
Kevin Phillips
@phillipskevin
Nov 30 2018 22:19
Frank Lemanschik
@frank-dspeed
Nov 30 2018 22:19
then in the code of a other property let is set myResult to something else
oh he is right
for me can-ajax looks like blocking code
why isn't that code inside the Promise that get returned?
Kevin Phillips
@phillipskevin
Nov 30 2018 22:23
what?
RyanMilligan
@RyanMilligan
Nov 30 2018 22:23
Putting something inside a Promise doesn't make it asynchronous. If the code that resolves the Promise blocks execution, then the promise won't be returned until after it's been resolved. JavaScript is a fundamentally single-threaded environment.
Frank Lemanschik
@frank-dspeed
Nov 30 2018 22:24
thats right
if the resolver blocks
RyanMilligan
@RyanMilligan
Nov 30 2018 22:25
Normally xhr.open() with two parameters shouldn't block, which will return the Promise before it gets resolved, but for some reason, which appears to be some kind of Chrome bug, that's not always happening. It's like it's treating undefined as false for the async flag instead of true, which is supposed to be the default.
Frank Lemanschik
@frank-dspeed
Nov 30 2018 22:25
what chrome version do you use?
something current?
i am on nightly and can't reproduce it
RyanMilligan
@RyanMilligan
Nov 30 2018 22:26
70.0.3538.110 (Official Build) (64-bit)
Yeah, I'm not saying it's all the time. But it's happening for us on at least three different machines. But only in our internal environments, in production it works correctly. That's what's really weird about it.
Frank Lemanschik
@frank-dspeed
Nov 30 2018 22:27
ok then the best is to create a issue inside can-ajax
and let some one reproduce that or track that down
RyanMilligan
@RyanMilligan
Nov 30 2018 22:27
Frank Lemanschik
@frank-dspeed
Nov 30 2018 22:28
until that use your wrapper
that sounds like a good workaround
RyanMilligan
@RyanMilligan
Nov 30 2018 22:28
Not a lot of detail because I don't know exactly what's causing the issue, but yeah, the wrapper will allow us to keep working.
Frank Lemanschik
@frank-dspeed
Nov 30 2018 22:28
i will try to get that chrome version started inside docker and reproduce that
if its a chrome bug
i will fix it
your suggestion with undefined interpreted as false
is interristing
as we really do so in some code parts
undefined or even not true is === false
Kevin Phillips
@phillipskevin
Nov 30 2018 22:31
@RyanMilligan any more info you can give about your environment will help
someone should be able to look into it next week
do you maybe have can-fixture loaded?
Frank Lemanschik
@frank-dspeed
Nov 30 2018 22:34
oh yes because of its XHR HiJacking :)
Kevin Phillips
@phillipskevin
Nov 30 2018 22:34
would explain why it's only happening in development
Frank Lemanschik
@frank-dspeed
Nov 30 2018 22:34
but then this would not work in Firefox also
RyanMilligan
@RyanMilligan
Nov 30 2018 22:34
Hrm, maybe, but I was unable to step into the open that my wrapper is around, so I don't think so.
Kevin Phillips
@phillipskevin
Nov 30 2018 22:34
Firefox doesn't allow sync XHR anymore
on the main thread
RyanMilligan
@RyanMilligan
Nov 30 2018 22:35
Oh, and it's also happening in our deployed Test environment, not just literally when we have a debugger attached. I should have been cleared on that.
Kevin Phillips
@phillipskevin
Nov 30 2018 22:35
ok
RyanMilligan
@RyanMilligan
Nov 30 2018 22:35
We do have a dev dependency on can-fixture but I don't think we import it.
Kevin Phillips
@phillipskevin
Nov 30 2018 22:35
you should be able to find it in devtools if you are
RyanMilligan
@RyanMilligan
Nov 30 2018 22:36
Yeah, can-fixture.js isn't loaded.
Kevin Phillips
@phillipskevin
Nov 30 2018 22:36
ok
too bad :smile:
RyanMilligan
@RyanMilligan
Nov 30 2018 22:37
Looking at can-fixture's override, I bet it would actually work if we imported it, since it forces async to always be either true or false.
Kevin Phillips
@phillipskevin
Nov 30 2018 22:38
yeah