Closing cnn.com popup window crashes embedding app

RESOLVED FIXED

Status

()

Core
Document Navigation
--
critical
RESOLVED FIXED
17 years ago
17 years ago

People

(Reporter: Brian Ryner (not reading), Assigned: Adam Lock)

Tracking

({crash, topembed})

Trunk
x86
Windows 2000
crash, topembed
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: topembed+, URL)

Attachments

(1 attachment)

(Reporter)

Description

17 years ago
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.
(Reporter)

Updated

17 years ago
Keywords: crash

Comment 1

17 years ago
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

17 years ago
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...
Keywords: topembed
(Reporter)

Comment 3

17 years ago
branch
(Assignee)

Comment 4

17 years ago
works for me on the latest trunk, checking with 0.9.2
(Assignee)

Comment 5

17 years ago
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()
(Assignee)

Comment 6

17 years ago
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

17 years ago
get together with bryner on this bug, he has been looking at it too
(Assignee)

Comment 8

17 years ago
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.
(Assignee)

Comment 9

17 years ago
Created attachment 46218 [details] [diff] [review]
Patch (against 0.9.2) stops docshell from starting a load while its being destroyed. Reviews please

Comment 10

17 years ago
r/sr=rpotts
(Assignee)

Comment 12

17 years ago
Fix is checked into the trunk

Updated

17 years ago
Whiteboard: topembed+
(Assignee)

Comment 13

17 years ago
Fix is checked into branch. Marking FIXED
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.