CODEWITHSUNDEEP
ajaxxmlhttprequestmootools
kasimir
kasimir

Reputation: 1554

MooTools synchronous request makes 'onRequest' useless?

I have a couple of MooTools XHR requests which I want to handle synchronously. So I use the option async: false when creating a new request object and that works fine. However, I also want to inform the user that the browser will be busy. For this, I wanted to utilize onRequest, so when the request fires, it will show a message and then get busy, after which more stuff comes with onComplete.

However, the stuff I put in onRequest seems not to get executed. The request fires straight away, locks up the browser immediately and when it's done, the onComplete stuff comes. So does this make the onRequest option useless when combined with async: false? And what would a 'workaround' be? I guess chaining would do the trick, but that seems messy compared to simply utilizing onRequest.

Upvotes: 0

Views: 788

Answers (1)

Dimitar Christoff
Dimitar Christoff

Reputation: 26165

This is fishy - though I am not sure how it will behave cross-browser. What are you using? I don't experience the same myself in FireFox.

MooTools created xhr object first and then fires the onRequest event afterwards:

https://github.com/mootools/mootools-core/blob/master/Source/Request/Request.js#L199-212

it THEN does xhr.send(data); - there should NOT be any circumstance under which the browser will block the UI thread and not fire the event (the callback itself is asynchronous).

look at this example on jsfiddle with a 3 second delay in the response and an alert underneath that will fire when done, the onRequest fires correctly:

http://jsfiddle.net/dimitar/gDjJG/

worst case scenario, I suppose you could refactor Request.send to dispatch the event before it creates the xhr object instance but I don't see a need for it. Using sync ajax is defeatist and an anti-pattern, though it can potentially have a use in validation for username availability or whatever.

edit seems to break in webkit and block ui thread for DOM updates BEFORE the xhr.send. it appears to update the element property but QUEUEs the actual reflow for later. I will see if we can change mootools to fire the event before the xhr is set. good catch.

I have filed the ticket, watch it for a patch or do as suggested in worst case bit:

https://github.com/mootools/mootools-core/issues/2317

Upvotes: 2

Related Questions