94229 - Closing cnn.com popup window crashes embedding app

Status: RESOLVED FIXED

(Core :: DOM: Navigation, defect)

Description

[Brian Ryner (not reading)]

1. In mfcembed, go to http://cnn.com.
2. It will bring up a popup window asking you to set your edition (if it
doesn't, clear your cookies).
3. Click the "Don't show me this again" link
4. Crash

This seems to only affect embedding.  The interesting piece of HTML in the popup
window is this:

<a href="#" onclick="top.close();">don't show me this again</a>

We appear to be closing the window via the onclick handler, _then_ trying to
load the same URL plus "#" into the now-nonexistant window.

Comment 1

[Judson Valeski]

cc'ing rick potts. I thought we nailed this window.close() bug. perhaps this is
a new manifestation.? are you seeing this in the trunk or branch?

Comment 2

[chris hofmann]

sounds like this happens in the embedding customer build (based on 092 branch),
and I'm  guessing this will make it to the WarRoom list...

Comment 3

[Brian Ryner (not reading)]

branch

Comment 4

[Adam Lock]

works for me on the latest trunk, checking with 0.9.2

Comment 5

[Adam Lock]

0.9.2 branch definitely has problems. The crash is occurring when the incoming
HTTP data (from the anchor click) is parsed and a null pointer to the global
script object is called.

I'm trying to establish why the trunk doesn't run into similar problems.

nsDebug::Assertion(const char * 0x020f5d98 `string', const char * 0x020f5ddc
`string', const char * 0x020fd470 `string', int 649) line 290 + 13 bytes
nsDebug::PreCondition(const char * 0x020f5d98 `string', const char * 0x020f5ddc
`string', const char * 0x020fd470 `string', int 649) line 434 + 21 bytes
nsCOMPtr<nsIScriptGlobalObject>::operator->() line 649 + 34 bytes
nsScriptLoader::ProcessScriptElement(nsScriptLoader * const 0x0367ef90,
nsIDOMHTMLScriptElement * 0x02ab7de8, nsIScriptLoaderObserver * 0x02ab7dec) line
386 + 41 bytes
nsHTMLScriptElement::SetDocument(nsHTMLScriptElement * const 0x02ab7dc0,
nsIDocument * 0x02dbc028, int 0, int 1) line 145
nsGenericHTMLContainerElement::AppendChildTo(nsGenericHTMLContainerElement *
const 0x02b50398, nsIContent * 0x02ab7dc0, int 0, int 0) line 3745
HTMLContentSink::ProcessSCRIPTTag(const nsIParserNode & {...}) line 4974
HTMLContentSink::AddLeaf(HTMLContentSink * const 0x02bc16c8, const nsIParserNode
& {...}) line 3399 + 12 bytes
CNavDTD::AddLeaf(const nsIParserNode * 0x02cb8bc0) line 3789 + 22 bytes
CNavDTD::AddHeadLeaf(nsIParserNode * 0x02cb8bc0) line 3847 + 15 bytes
CNavDTD::HandleStartToken(CToken * 0x02bf2b18) line 1744 + 12 bytes
CNavDTD::HandleToken(CNavDTD * const 0x02babc78, CToken * 0x00000000, nsIParser
* 0x00f9c3b8) line 910 + 12 bytes
CNavDTD::BuildModel(CNavDTD * const 0x02babc78, nsIParser * 0x00f9c3b8,
nsITokenizer * 0x02a328a8, nsITokenObserver * 0x00000000, nsIContentSink *
0x02bc16c8) line 540 + 20 bytes
nsParser::BuildModel() line 2217 + 34 bytes
nsParser::ResumeParse(int 1, int 0) line 2083 + 11 bytes
nsParser::OnDataAvailable(nsParser * const 0x00f9c3c0, nsIRequest * 0x00fc1028,
nsISupports * 0x00000000, nsIInputStream * 0x02ba1fe0, unsigned int 0, unsigned
int 11144) line 2688 + 19 bytes
nsDocumentOpenInfo::OnDataAvailable(nsDocumentOpenInfo * const 0x02c701d8,
nsIRequest * 0x00fc1028, nsISupports * 0x00000000, nsIInputStream * 0x02ba1fe0,
unsigned int 0, unsigned int 11144) line 235 + 46 bytes
nsStreamListenerTee::OnDataAvailable(nsStreamListenerTee * const 0x02c78af0,
nsIRequest * 0x00fc1028, nsISupports * 0x00000000, nsIInputStream * 0x02b659c8,
unsigned int 0, unsigned int 11144) line 56 + 51 bytes
nsHttpChannel::OnDataAvailable(nsHttpChannel * const 0x00fc102c, nsIRequest *
0x02a2efb8, nsISupports * 0x00000000, nsIInputStream * 0x02b659c8, unsigned int
0, unsigned int 11144) line 2173 + 57 bytes
nsOnDataAvailableEvent::HandleEvent() line 178 + 70 bytes
nsARequestObserverEvent::HandlePLEvent(PLEvent * 0x02c63f94) line 64
PL_HandleEvent(PLEvent * 0x02c63f94) line 590 + 10 bytes
PL_ProcessPendingEvents(PLEventQueue * 0x00f41e98) line 520 + 9 bytes
_md_EventReceiverProc(HWND__ * 0x001304d0, unsigned int 49437, unsigned int 0,
long 15998616) line 1071 + 9 bytes
USER32! 77e148dc()
USER32! 77e14aa7()
USER32! 77e266fd()
CWinThread::Run() line 480 + 11 bytes
CWinApp::Run() line 400
AfxWinMain(HINSTANCE__ * 0x00400000, HINSTANCE__ * 0x00000000, char *
0x00133a50, int 1) line 49 + 11 bytes
WinMain(HINSTANCE__ * 0x00400000, HINSTANCE__ * 0x00000000, char * 0x00133a50,
int 1) line 30
WinMainCRTStartup() line 330 + 54 bytes
KERNEL32! 77e992a6()

Comment 6

[Adam Lock]

CC'ing Dan.

Does anyone know offhand whether a link click on an anchor should even be
processed if there's a JS onclick handler?

Comment 7

[saari (gone)]

get together with bryner on this bug, he has been looking at it too

Comment 8

[Adam Lock]

Solution is turns out to be quite simple. Add a check to
nsDocShell::InternalLoad to prevents loading from continuing if the targetted
docshell is being destroyed.

Patch follows.

Comment 9

[Adam Lock]

Attachment: Patch (against 0.9.2) stops docshell from starting a load while its being destroyed. Reviews please

Comment 10

[rpotts (gone)]

r/sr=rpotts

Comment 11

[Conrad Carlen (not reading bugmail)]

r=ccarlen

Comment 12

[Adam Lock]

Fix is checked into the trunk

Comment 13

[Adam Lock]

Fix is checked into branch. Marking FIXED