You need to
before you can comment on or make changes to this bug.
1. Nightly build
2. Windows Live Account
1. Download the nightly build
2. Enter http://dev.live.com/mashups/trycontactscontrol as URL and press enter
3. On the right there is a box with title "Windows Live Contacts Beta"
4. Select Sign In
5. A New window will appear
6. Enter your data and select sign in
7. Window disappears and the box on the right will show "Loading.."
8. Safari will crash
Hi Tom, thanks for the bug report! Could you post a stack trace either as an attachment or as a comment on this bug? Thanks!
This looks like more frame wackiness. Reproducible crashers are P1.
Verified with a local debug build of WebKit r20699 with Safari 2.0.4 (419.3) on Mac OS X 10.4.9 (8P135).
Exception: EXC_BAD_ACCESS (0x0001)
Codes: KERN_PROTECTION_FAILURE (0x0002) at 0x00000080
Thread 0 Crashed:
0 com.apple.WebCore 0x01647a78 KJS::Window::frame() const + 20 (kjs_window.h:108)
1 com.apple.WebCore 0x012d0fac KJS::JSAbstractEventListener::handleEvent(WebCore::Event*, bool) + 148 (kjs_events.cpp:81)
2 com.apple.WebCore 0x01206d5c WebCore::XMLHttpRequest::callReadyStateChangeListener() + 388 (xmlhttprequest.cpp:305)
3 com.apple.WebCore 0x012070d4 WebCore::XMLHttpRequest::changeState(WebCore::XMLHttpRequestState) + 68 (xmlhttprequest.cpp:297)
4 com.apple.WebCore 0x01207130 WebCore::XMLHttpRequest::didReceiveData(WebCore::SubresourceLoader*, char const*, int) + 72 (xmlhttprequest.cpp:656)
5 com.apple.WebCore 0x01481038 WebCore::SubresourceLoader::didReceiveData(char const*, int, long long, bool) + 180 (SubresourceLoader.cpp:177)
6 com.apple.WebCore 0x0147f358 WebCore::ResourceLoader::didReceiveData(WebCore::ResourceHandle*, char const*, int, int) + 108
7 com.apple.WebCore 0x014558dc -[WebCoreResourceHandleAsDelegate connection:didReceiveData:lengthReceived:] + 244 (ResourceHandleMac.mm:352)
8 com.apple.Foundation 0x92c13624 -[NSURLConnection(NSURLConnectionInternal) _sendDidReceiveDataCallback] + 564
9 com.apple.Foundation 0x92c11ac4 -[NSURLConnection(NSURLConnectionInternal) _sendCallbacks] + 488
10 com.apple.Foundation 0x92c11860 _sendCallbacks + 156
11 com.apple.CoreFoundation 0x907df4fc __CFRunLoopDoSources0 + 384
12 com.apple.CoreFoundation 0x907dea2c __CFRunLoopRun + 452
13 com.apple.CoreFoundation 0x907de4ac CFRunLoopRunSpecific + 268
14 com.apple.HIToolbox 0x93298b20 RunCurrentEventLoopInMode + 264
15 com.apple.HIToolbox 0x9329812c ReceiveNextEventCommon + 244
16 com.apple.HIToolbox 0x93298020 BlockUntilNextEventMatchingListInMode + 96
17 com.apple.AppKit 0x9379eae4 _DPSNextEvent + 384
18 com.apple.AppKit 0x9379e7a8 -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 116
19 com.apple.Safari 0x00006740 0x1000 + 22336
20 com.apple.AppKit 0x9379acec -[NSApplication run] + 472
21 com.apple.AppKit 0x9388b87c NSApplicationMain + 452
22 com.apple.Safari 0x0005c77c 0x1000 + 374652
23 com.apple.Safari 0x0005c624 0x1000 + 374308
This Live.com account from Bug 5695 Comment #14 may be used to test with:
(In reply to comment #3)
> This Live.com account from Bug 5695 Comment #14 may be used to test with:
> User: firstname.lastname@example.org
> Pass: w3bk1t
This used to go to mail.live.com when checking mail, but the account was reset, so it's back to Hotmail. It still crashes when logging in while testing this bug.
Created an attachment (id=13954) [details]
Full crash log
This is the full crash log as reported by the Console.app. Thanks for being on top of this David
Created an attachment (id=14535) [details]
Patch (no layout test)
This fixes the problem as the XMLHttpRequest returns after the window has been destroyed, causing a null dereference.
I'm not sure how (or if it's possible) to make a layout test for this: we need to have an xmlhttprequest return data after a window has already been destroyed. Pointers as to how (if possible) to do a layout test would be great.
(In reply to comment #7)
> I'm not sure how (or if it's possible) to make a layout test for this: we need
> to have an xmlhttprequest return data after a window has already been
If I understood the problem correctly, you can use something similar to http/tests/xmlhttprequest/resources/endlessxml.php.
I think the real fix would be to make XHR hold a reference to window, as per the draft spec. But maybe plugging the crasher like this is OK for now.
(From update of attachment 14535 [details])
I would like to see a comment explaining the null check here, and a reference to this bug.
Committed with a comment above the null check as suggested by Anders. I wasn't able to create a LayoutTest to reliably reproduce the issue however, so no layout test is included.