Version 1999100618 minimal test case at: http://www.concentric.net/~Ventifus/mozbug.html (click on the "options" link to reproduce the bug.) I'm not sure exactly how to discribe this problem. I'm guessing that there is some kind of interaction between the css link properties and the javascript that is locking apprunner. With the css removed, it works correctly, and with the javascript function empty it works correctly.

Guessing it's not a javascript core language issue. Style sheets?

This causes two asserts for me on NT, neither anywhere near style code. The first in nsFileTransport.cpp: line 761: case READING: { NS_ASSERTION(mTransferAmount >= 0, "bad mTransferAmount in READING"); NTDLL! 77f7629c() nsDebug::Assertion(const char * 0x014f7980, const char * 0x014f7968, const char * 0x014f7938, int 762) line 280 + 13 bytes nsFileTransport::Process() line 762 + 38 bytes nsFileTransport::Run(nsFileTransport * const 0x01f59654) line 658 nsThreadPoolRunnable::Run(nsThreadPoolRunnable * const 0x010a9710) line 590 + 12 bytes nsThread::Main(void * 0x010a9570) line 79 + 26 bytes _PR_NativeRunThread(void * 0x010a9380) line 385 + 13 bytes _threadstartex(void * 0x010a91d0) line 212 + 13 bytes continuing past that I hit, jslock.c line 259: JS_ASSERT(me == CurrentThreadId()); NTDLL! 77f7629c() js_GetSlotWhileLocked(JSContext * 0x01adfb20, JSObject * 0x012af138, unsigned long 2) line 258 + 39 bytes JS_GetPrivate(JSContext * 0x01adfb20, JSObject * 0x012af138) line 1325 + 98 bytes nsJSContext::GetGlobalObject(nsJSContext * const 0x01adf6e0) line 252 + 17 bytes nsJSContext::EvaluateString(nsJSContext * const 0x01adf6e0, const nsString & {"openNewWindow('/exchange/options/set.asp','userOptionsWindow',620,500)"}, void * 0x012af138, nsIPrincipal * 0x00000000, const char * 0x00000000, unsigned int 0, nsString & {""}, int * 0x0165fbc0) line 159 + 12 bytes nsJSInputStream::Eval() line 165 + 65 bytes nsJSInputStream::Available(nsJSInputStream * const 0x01f58570, unsigned int * 0x0165fc90) line 105 + 8 bytes nsJSInputStream::Read(nsJSInputStream * const 0x01f58570, char * 0x01253028, unsigned int 2048, unsigned int * 0x0165fcd4) line 120 + 16 bytes nsReadFromInputStream(void * 0x01f58570, char * 0x01253028, unsigned int 0, unsigned int 2048, unsigned int * 0x0165fcd4) line 747 nsPipe::nsPipeOutputStream::WriteSegments(nsPipe::nsPipeOutputStream * const 0x01f592f4, unsigned int (void *, char *, unsigned int, unsigned int, unsigned int *)* 0x00265890 nsReadFromInputStream(void *, char *, unsigned int, unsigned int, unsigned int *), void * 0x01f58570, unsigned int 4294967295, unsigned int * 0x0165ff0c) line 635 + 25 bytes nsPipe::nsPipeOutputStream::WriteFrom(nsPipe::nsPipeOutputStream * const 0x01f592f4, nsIInputStream * 0x01f58570, unsigned int 4294967295, unsigned int * 0x0165ff0c) line 755 nsFileTransport::Process() line 765 + 67 bytes nsFileTransport::Run(nsFileTransport * const 0x01f59654) line 658 nsThreadPoolRunnable::Run(nsThreadPoolRunnable * const 0x010a9710) line 590 + 12 bytes nsThread::Main(void * 0x010a9570) line 79 + 26 bytes _PR_NativeRunThread(void * 0x010a9380) line 385 + 13 bytes _threadstartex(void * 0x010a91d0) line 212 + 13 bytes KERNEL32! 77f04ee8() Handing off to Necko for the first...

updating qa contact

This looks like a dupe of one of Warren's bugs. Assiging to him.

I'm not seeing any deadlock, nor the assertion given. Try turning on NSPR_LOG_MODULES=nsFileTransport:5 and seeing what's going on there. Or if it no longer happens, mark it WORKSFORME.

Dosn't seem to happen anymore. Changing to WORKSFORME.

Bulk move of all Necko (to be deleted component) bugs to new Networking component.

working for original reporter. Closing.