[Greasemonkey] xmlhttp and overrideMimeType to solve non UTF-8 trouble

[Johan Sundström]

>> While I technically don't quite qualify as a GM dev, I'm very much in
>> agreement. Exposing that would be the pragmatic approach "on our end"
>> to enabling cross-site GM scripts that run into this problem to work
>> at all, prior to a proper fix for the underlying Mozilla bug
>
> I dub thee an honorary member.  ;-)

Heh, thanks. :-)

> I'm surprised that Moz seems to be assuming that a document and all
> it's resources will be represented in only one encoding.
>
> Anyway, yeah, thanks for the pointer and as soon as I understand what
> it's actually doing, I think it should be included.

While that probably refers to "how it's accomplishing what it's
doing", here is some noise, in case it wasn't. The override just hints
the charset decoder to not assume UTF-8 (or whichever encoding it
wasn't, though my experience suggests that it's always assuming that)
and use the provided encoding instead.

It seems to work beautifully too, and this was a good reminder for me
not to use GM_xmlhttpRequest except where necessary to bypass the same
domain jail.

That practice that is good for portability too, though as my scripts
tend to grow until they use GM_setValue and GM_getValue too it
probably won't matter much in practice. :-) I'm hoping to eventually
have all the userscript environment variants unite around some common
ground to standardize us back into interoperability land again, but
that's most likely a post-2006 project and one I'll have to work with
Opera on too. But now I drifted off subject.

I thought I'd suggest the GM wrapper for this kludge not to use a
method, but just allow it as another property of the details passed to
the GM_xmlhttpRequest() call. Assumedly the same thought that would
occur to any other implementor, given the nature of our wrapped API,
but won't hurt requesting either. :-)

-- 
 / Johan Sundström, http://ecmanaut.blogspot.com/