Overhauling the XMLHttpRequest documentation
Today I finally got around to rewriting the XMLHttpRequest documentation on MDC. The documentation has been a mess for a long time, and I’ve been meaning to redo it for a couple of years now.
With the large number of XHR changes in Firefox 3.1, it seemed like a good time to break down and take care of it.
There’s work to be done yet (some of the stuff that’s new in Gecko 1.9.1 is not labeled as such yet, for example, and there are no examples for the new capabilities yet either), but it’s a definite improvement, I think.
Instead of one article providing documentation-by-example, there’s now a reference for XMLHttpRequest as well as an article on how to use XMLHttpRequest, which includes the examples.
I’m glad to finally have this done, and look forward to getting the cool new capabilities we’ve added in Firefox 3.1 properly documented over the next day or so.
October 16th, 2008 at 8:26 PM
ah nice. thanks.
I hated it not having a good documentation about the XHR implementation in Mozilla. Also multipart! great! <3
October 16th, 2008 at 10:43 PM
Looks good! I wrote the original page on kb.mozillazine.org a while back, and copied it to MDC at some point. It wasn’t great, but it was better than nothing. Now it’s well-organized and useful!
October 17th, 2008 at 2:30 AM
Great, great, great! The new version is a lot clearer!
I’ve got a question though: the callback handler – does it run on the spawned thread or on the GUI thread?
October 17th, 2008 at 9:50 AM
I would remove the high-order bit instead of the byte, I guess, you don’t have much left if you remove the whole byte of a character…
SendAsBinary: The request body as a DOM string. This data is converted to a string of single-byte characters by truncation (removing the high-order !!!byte!!! of each character).
October 17th, 2008 at 9:57 AM
seems we’re talking about 16bits chars… (utf8?)
October 17th, 2008 at 10:41 AM
Yes, these are 16 bit characters, which is why the high byte gets stripped off to create bytes.
October 17th, 2008 at 10:41 AM
Vladimir: The callback handler runs on the GUI thread; otherwise you wouldn’t have access to the DOM.
October 24th, 2008 at 3:10 AM
Sheppy, thank you for the clarification
Today I was trying to find out why the FF3 UI doesn’t freeze on blocking XHR calls (as with earlier versions). I’m developing a standalone xulrunner app and it seems that now the main argument for using asynchronous XHR calls – preventing UI lock-up – is gone. Has synchronous XHR become “safe” now?
Strangely, I couldn’t find any info on this programming issue! It’s important to me because it gives me an option to simplify programming throughout the whole application.
October 24th, 2008 at 2:47 PM
Vladimir Dzhuvinov –
Firefox 3 no longer blocks the UI when handling synchronous XMLHttpRequests, because otherwise there’s no way for the user to terminate one that’s locked up. It’s strongly recommended that you avoid using synchronous requests, because they can leak in various ways, and asynchronous just isn’t that much more complicted.
October 29th, 2008 at 2:02 AM
Leaks as in “memory leaks”?
I searched bugzilla for “xmlhttprequest + memory + leak” and couldn’t find any applicable confirmed bugs.
If we put aside good programming practice for a moment, are there really bad things lurking in synchronous XHR?