these urls cause nsGenericElement crash or minimize browser



18 years ago
5 months ago


(Reporter: depman1, Assigned: joki)


({crash, topembed})

Windows NT
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)


(Whiteboard: ETA 9/28)

0.9.3 mozilla full build 20010807. 
1. Launch mozilla.exe or mfcEmbed.
2. Load one of these:

Result: Get this assert: NS_ENSURE_TRUE(context) failed: 'context', file 
/mozilla/content/base/src/nsGenericElement.cpp line 2677.

call stack:
nsDebug::Assertion(const char * 0x01ca483c, const char * 0x01ca4834, const char
* 0x01ca47f4, int 2677) line 290 + 13 bytes
nsDebug::WarnIfFalse(const char * 0x01ca483c, const char * 0x01ca4834, const
char * 0x01ca47f4, int 2677) line 396 + 21 bytes
nsGenericElement::AddScriptEventListener(nsIAtom * 0x0118f530, const nsAString &
{...}) line 2677 + 38 bytes
nsGenericHTMLElement::SetAttribute(nsGenericHTMLElement * const 0x02f03aa0, int
3, nsIAtom * 0x0118f530, const nsAString & {...}, int 0) line 1467
HTMLContentSink::AddAttributes(const nsIParserNode & {...}, nsIHTMLContent *
0x02f03aa0, int 0) line 781
SinkContext::OpenContainer(const nsIParserNode & {...}) line 1468 + 20 bytes
HTMLContentSink::OpenBody(HTMLContentSink * const 0x02eeadc0, const
nsIParserNode & {...}) line 3132 + 18 bytes
CNavDTD::OpenBody(const nsCParserNode * 0x00fe00a8) line 3106 + 31 bytes
CNavDTD::OpenContainer(const nsCParserNode * 0x00fe00a8, nsHTMLTag
eHTMLTag_body, int 1, nsEntryStack * 0x00000000) line 3363 + 12 bytes
CNavDTD::HandleDefaultStartToken(CToken * 0x028625b0, nsHTMLTag eHTMLTag_body,
nsCParserNode * 0x00fe00a8) line 1291 + 20 bytes
CNavDTD::HandleStartToken(CToken * 0x028625b0) line 1701 + 22 bytes
CNavDTD::HandleToken(CNavDTD * const 0x02e62a40, CToken * 0x028625b0, nsIParser
* 0x02ee8250) line 870 + 12 bytes
CNavDTD::BuildModel(CNavDTD * const 0x02e62a40, nsIParser * 0x02ee8250,
nsITokenizer * 0x02e62770, nsITokenObserver * 0x00000000, nsIContentSink *
0x02eeadc0) line 506 + 20 bytes
nsParser::BuildModel() line 2219 + 34 bytes
nsParser::ResumeParse(int 1, int 0) line 2085 + 11 bytes
nsParser::OnDataAvailable(nsParser * const 0x02ee8258, nsIRequest * 0x01f82660,
nsISupports * 0x00000000, nsIInputStream * 0x02e62d40, unsigned int 0, unsigned
int 1387) line 2690 + 19 bytes
nsDocumentOpenInfo::OnDataAvailable(nsDocumentOpenInfo * const 0x01f831d0,
nsIRequest * 0x01f82660, nsISupports * 0x00000000, nsIInputStream * 0x02e62d40,
unsigned int 0, unsigned int 1387) line 241 + 46 bytes
nsStreamListenerTee::OnDataAvailable(nsStreamListenerTee * const 0x02e5b160,
nsIRequest * 0x01f82660, nsISupports * 0x00000000, nsIInputStream * 0x01f83a20,
unsigned int 0, unsigned int 1387) line 56 + 51 bytes
nsHttpChannel::OnDataAvailable(nsHttpChannel * const 0x01f82664, nsIRequest *
0x01f836d0, nsISupports * 0x00000000, nsIInputStream * 0x01f83a20, unsigned int
0, unsigned int 1387) line 2179 + 57 bytes
nsOnDataAvailableEvent::HandleEvent() line 178 + 70 bytes
nsARequestObserverEvent::HandlePLEvent(PLEvent * 0x02f0e4b4) line 64
PL_HandleEvent(PLEvent * 0x02f0e4b4) line 590 + 10 bytes
PL_ProcessPendingEvents(PLEventQueue * 0x010ebae0) line 520 + 9 bytes
_md_EventReceiverProc(HWND__ * 0x002301fa, unsigned int 49394, unsigned int 0,
long 17742560) line 1071 + 9 bytes
USER32! 77e71820()
Blocks: 90787
Re-assigning to saari since this is not embedding specific.

Hi Chris,

I saw your name in cvs blame for this part. Please re-assign to the appropriate
person if you're not the owner.

Assignee: chak → saari
->joki for a general event bug
Assignee: saari → joki
per WRMB discussion, making dependent of 90787 topembed.
Keywords: topembed
the first 2 urls are closing (or minimizing) the browser in the 8/17 nightly
build. The last one ( worked the first
time, but shut down the browser on subsequent trials.
Making nsbranch+ since topembed, adding crash keyword.

Also scheduling for 0.9.4, but the fix needs to go into the 0.9.2 branch as well.
Severity: normal → critical
Keywords: crash, nsbranch+
Priority: -- → P1
Target Milestone: --- → mozilla0.9.4
Joki - What's the ETA for this one (i.e. Will it be completed by 08/31)?
Target Milestone: mozilla0.9.4 → mozilla0.9.5
talked to tom, said he is having issues reproducing this and hasn't yet gotten
it to crash
The last url, the crasher appears to be out of date, and doesn't seem to crash
for me on Win2k. Is it still crashing others?
QA Contact: mdunn → depstein
In mozilla 0.9.4 branch, the 1st 2 urls minimize the window, then close it. The
3rd url loads fine.
Whiteboard: ETA 9/28
Sorry, some confusion on my part.  I thought that by 'minimize' we were talking
about the system-type minimizing to the taskbar.  The behavior it has, of
resizing to the very small window, is coded into the app and is its intentional
way of trying to hide itself.  As for the crash, there doesn't seem to be one
anymore.  It does seem to check for a cookie and close itself (and thereby the
browser if you only have one window up) if it finds the cookie.  Once again,
this seems to be intended behavior.  This is also why it sometimes closes the
app and sometimes does not.  If you reset your cookies it will again function. 
Which is to say it will try to hide its main window while using a timer to pop
up new advertisement windows which all have unload handlers to attempt to
relaunch if you close them.  If you try this in IE it also tries to reset your
home page.

This behavior, while odd, all seems to be intended.  Behavior is the same under
Nav4x and IE.  I'm going to have to go with WORKSFORME on this.
Closed: 18 years ago
Resolution: --- → WORKSFORME
The only difference between N6.1 and IE5.5, for the 2nd url anyway, is that IE
displays "The web page you're viewing is trying to close the window. Do you want
to close the window? Yes/No". Is this approach being considered for NS?
I just saw the comments for bug 90787, so that answered my question about the
window closing dialog. Thanks for looking at this.
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.