Made a test from my machine at work and there it works.
One difference I found was in the url sent from ajax.
he bad behaviour probably came from the null:null@ prepended to the url.
I will check my config if there is a plugin that caused this and if I can still repeat the error.
The last leg from my run at work:
http://lab.dnet.nu/fftest/server.php?cmd=logelist&AjaxRequestUniqueId=11489157125270
GET /fftest/server.php?cmd=logelist&AjaxRequestUniqueId=11489157125270 HTTP/1.1
Host: lab.dnet.nu
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.3) Gecko/20060426 Firefox/1.5.0.3
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Authorization: Basic ZmZ0ZXN0OmZpcmVmb3g=
HTTP/1.x 200 OK
Date: Mon, 29 May 2006 16:12:47 GMT
Server: Apache/2.0.55 (Trustix Secure Linux/Linux) PHP/5.0.5 mod_perl/2.0.0 Perl/v5.8.7
X-Powered-By: PHP/5.0.5
Content-Length: 1074
Keep-Alive: timeout=15, max=97
Connection: Keep-Alive
Content-Type: text/html; charset=iso-8859-1
----------------------------------------------------------

New test from home with -safe-mode.
Error persists.
I verified it on another computer at home, one XP proffesional and one Home edition.
But on the computer at work it apperently works, thats XP proffesional.
Either I have a plugin that neutrelizes the error at work or there is some other setting i FF that affects the error.
My work computer is the most customized regarding settings as it is the one I spend most time at.
I will continue to test at work to see if I can repeat the error there but I would appreciate if some one else could try it preferebly on linux or mac to eliminate OS dependensy.

(In reply to comment #0)
>
> I have tested with long timeouts and it does not work anyway
>
> This works with IE 6.0 and Opera 8.51
OK, it looks like your Ajax library sends a user/pass even when they are null, and we are turning those into "null"/"null" creds. Probably bad, and I verified that it works in Opera.

Retested at work with safe mode and then the error repeats it self.
Either this means that some extension fixes the error or theer is some setting in safe mode that does it.
I have the following extensions at work:
DOM Inspector 1.8.0.3
Talkback 1.5.0.3
Gmail Notifier 0.5.5.5
FirefoxView 0.31.2
Context Highlight 0.2
Context Search 0.2.1
Web Developer 1.0.2
Javascript Debugger 0.9.87
ColorZilla 0.8.3.1
Live HTTP Headers 0.11
J2SE Update 6
AdBlock Plus 0.5.11.3
Html Validator 0.7.9
Javascript Console Plus 0.1.2005042201
FireBug 0.4
Will supply a list from home later today.
Are there any other filer or settings you could use to identify the difference between safe mode and normal operation at work as this could narrow down the problem or offer a quick fix for users encountering the problem?

I checked on the open function as it is described in MSDN and is states the following
==========================
sUser Optional. Variant that specifies the name of the user for authentication. If this parameter is null ("") or missing and the site requires authentication, the component displays a logon window.
sPassword Optional. Variant that specifies the password for authentication. This parameter is ignored if the user parameter is null ("") or missing.
=============================
http://msdn.microsoft.com/workshop/author/dhtml/reference/methods/open.asp
And this
===============================
Although this method accepts credentials passed via parameter, those credentials are not automatically sent to the server on the first request. The bstrUser and bstrPassword parameters are not sent to the server unless the server challenges the client for credentials with a 401 - Access Denied response.
===============================
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/xmlsdk/html/52aaf5ff-e302-4490-821a-cb3a085fe5ee.asp
I interptet this to mean that null values should ONLY be regardet if the server requests auth with an 401. but as basic auth is sent in the call, the server never requests authentication.
I also found this on W3.org
============================
Calling this method MUST initialise the object by remembering the method, uri, async (defaulting to true if omitted), user (defaulting to null if omitted), and password (defaulting to null if omitted) arguments, setting the readyState attribute to 1 (Open), resetting the responseText, responseXML, status, and statusText attributes to their initial values, and resetting the list of request headers.
Same-origin security restrictions SHOULD apply.
If the URI given to this method contains a user name and a password (the latter potentially being the empty string), then these MUST be used if the user and password arguments are omitted. If the arguments are not omitted, they take precedence, even if they are null.
================================
http://www.w3.org/TR/XMLHttpRequest/
This does not state how to behave when auhthentication is not requested so I belive FF should go with the IE and Opera behaviour and suggest to W3 to include this in the draft for clarification.
I have tested all extensions and I have yet to find any solution to why this works with my FF at work but not at home or on my portable.
As for my sites requirements I can just change the ajaxrequest code so that the problem never arises. I will also contact the author of the library and inform him about the problem.
Still, this script is quite widely used, maybe just not with authentication so the problem can resurface.

(In reply to comment #9)
>
> Any reason not to add the null and undefined checks to the earlier if (argc >
> 3) check here to avoid calling JS_ValueToString() on a value we know we won't
> be using?
That's how I had it originally, but then I thought about the case of an empty username and non-empty password (which could definitely happen with this dhtml library). I looked at the WHATWG spec, but didn't see anything on that case. I figured OpenRequest should be the place where that decision is made.
Happy to change it back, though

(In reply to comment #13)
> Please land on the 1.8 branch and add the approval1.8.0.5? flag
I should have been clearer, we (1.8.0.x drivers) want it landed on the 1.8 branch first, but you needed to get 1.8.1 approval from appropriate module owners to do so. That's part of our test: if they don't approve it for 1.8.1 then it's certainly not appropriate for 1.8.0.x
No harm done, though.