The request fires on time, we just have it in the wrong place as it seems that webkit won't allow DOM updates once the xhr object exists with async...
it looks as if as soon as the xhr object is created with async: false, webkit locks the UI thread for DOM manipulations so that the onRequest DOM update never arrives. It does run the callback but the visual update does not happen until the UI thread is unlocked. in the test you can query back the html property of the element and it is correct, although it's not so on-screen.
possible solution would be to move the fireEvent further up before the xhr.open - what downsides can there be? I suppose if setRequesHeaders fails, it's not nice to have dispatched the onRequest before the onException - though I see little options...
works as expected in gecko.
update also fails in IE9
Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.
can confirm in Chrome (17.0.963.56 m); @ IR9 even worser with staying the first alert() while the three seconds.
this does not fix it even though the request fires before the xhr.open, the function does not actually update the DOM until the response arrives.