Oct 162008

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.

 Posted by at 6:07 PM

  10 Responses to “Overhauling the XMLHttpRequest documentation”

  1. ah nice. thanks.

    I hated it not having a good documentation about the XHR implementation in Mozilla. Also multipart! great! <3

  2. 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!

  3. 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?

  4. 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).

  5. seems we’re talking about 16bits chars… (utf8?)

  6. Yes, these are 16 bit characters, which is why the high byte gets stripped off to create bytes.

  7. Vladimir: The callback handler runs on the GUI thread; otherwise you wouldn’t have access to the DOM.

  8. 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.

  9. 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.

  10. 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?

This site uses Akismet to reduce spam. Learn how your comment data is processed.