Closed Bug 90787 Opened 23 years ago Closed 8 years ago

WRMB: some urls are closing windows (Yes/No prompt before closing?)

Categories

(Core Graveyard :: Embedding: APIs, enhancement)

x86
Windows NT
enhancement
Not set
normal

Tracking

(Not tracked)

RESOLVED INCOMPLETE
Future

People

(Reporter: depman1, Unassigned)

References

()

Details

(Whiteboard: [bugscape: 7979])

Attachments

(1 file)

7/9 embedding build with testembed. Also happens in mfcEmbed. I've tried this
with various flags & urls, but have only seen this with www.cisco.com so far.
Will investigate.
1. Launch testembed. /mozilla/dist/Win32_d.obj/bin/testembed.exe
2. Select TestYourMethod from Tools menu.
3. Press OK in alert dlog. This is to load cisco.com. Occasionally, I got this
nsDebug assertion: NS_ENSURE_TRUE(NS_SUCCEEDED(results)') failed '(!((result) &
0x ...)', file ..\mozilla\htmlparser\src\nsHTMLTokens.cpp, line 1974. See call
stack below:
4. If no assert, press OK to reload url.
Result: nsDebug assertion: new cache entry for READ-ONLY request:
'*accessGranted' file ..\mozilla\netwerk\cache\src\nsCacheEntry.cpp, line 233.

Here's call stack for 1st assert (step 3)
nsDebug::Assertion(const char * 0x01944b5c, const char * 0x01944b40, const char
* 0x01944b08, int 1974) line 290 + 13 bytes
nsDebug::WarnIfFalse(const char * 0x01944b5c, const char * 0x01944b40, const
char * 0x01944b08, int 1974) line 396 + 21 bytes
CEntityToken::ConsumeEntity(unsigned short 38, nsString & {...}, nsScanner &
{...}) line 1974 + 38 bytes
ConsumeAttributeEntity(nsString & {...}, nsScanner & {...}, int 2082) line 1485
+ 21 bytes
ConsumeAttributeValueText(nsString & {...}, nsScanner & {...}, const unsigned
short * 0x0012e800, int 2082) line 1555 + 17 bytes
ConsumeQuotedString(unsigned short 34, nsString & {...}, nsScanner & {...}, int
2082) line 1591 + 21 bytes
CAttributeToken::Consume(unsigned short 34, nsScanner & {...}, int 2082) line
1679 + 25 bytes
nsHTMLTokenizer::ConsumeAttributes(unsigned short 83, CStartToken * 0x02a2edd0,
nsScanner & {...}) line 610 + 27 bytes
nsHTMLTokenizer::ConsumeStartTag(unsigned short 83, CToken * & 0x02a2edd0,
nsScanner & {...}, int & 0) line 735 + 30 bytes
nsHTMLTokenizer::ConsumeTag(unsigned short 73, CToken * & 0x02a2edd0, nsScanner
& {...}, int & 0) line 577 + 28 bytes
nsHTMLTokenizer::ConsumeToken(nsScanner & {...}, int & 0) line 489 + 28 bytes
nsParser::Tokenize(int 0) line 2782 + 28 bytes
nsParser::ResumeParse(int 1, int 0) line 2076 + 12 bytes
nsParser::OnDataAvailable(nsParser * const 0x037371d8, nsIRequest * 0x03728040,
nsISupports * 0x00000000, nsIInputStream * 0x01fa6a60, unsigned int 0, unsigned
int 16384) line 2673 + 19 bytes
nsDocumentOpenInfo::OnDataAvailable(nsDocumentOpenInfo * const 0x0372d0c0,
nsIRequest * 0x03728040, nsISupports * 0x00000000, nsIInputStream * 0x01fa6a60,
unsigned int 0, unsigned int 16384) line 235 + 46 bytes
nsStreamListenerTee::OnDataAvailable(nsStreamListenerTee * const 0x01fa6ab0,
nsIRequest * 0x03728040, nsISupports * 0x00000000, nsIInputStream * 0x037090d0,
unsigned int 0, unsigned int 16384) line 56 + 51 bytes
nsHttpChannel::OnDataAvailable(nsHttpChannel * const 0x03728044, nsIRequest *
0x0370d9e0, nsISupports * 0x00000000, nsIInputStream * 0x037090d0, unsigned int
0, unsigned int 16384) line 2146 + 57 bytes
nsOnDataAvailableEvent::HandleEvent() line 175 + 70 bytes
nsARequestObserverEvent::HandlePLEvent(PLEvent * 0x03716d44) line 64
PL_HandleEvent(PLEvent * 0x03716d44) line 590 + 10 bytes
PL_ProcessPendingEvents(PLEventQueue * 0x0118b3c0) line 520 + 9 bytes
_md_EventReceiverProc(HWND__ * 0x005008ea, unsigned int 49512, unsigned int 0,
long 18396096) line 1071 + 9 bytes
USER32! 77e71820()
0118

Here's call stack for reload (step 4):

NTDLL! 77f7629c()
nsDebug::Assertion(const char * 0x0282e90c, const char * 0x0282e8fc, const char
* 0x0282e8c0, int 233) line 290 + 13 bytes
nsCacheEntry::RequestAccess(nsCacheRequest * 0x030e5f70, int * 0x0012dbfc) line
233 + 34 bytes
nsCacheService::ProcessRequest(nsCacheRequest * 0x030e5f70, int 1,
nsICacheEntryDescriptor * * 0x0012dcd0) line 730 + 16 bytes
nsCacheService::OpenCacheEntry(nsCacheSession * 0x02e685c0, const char *
0x030e3f10, int 1, int 1, nsICacheListener * 0x00000000, nsICacheEntryDescriptor
* * 0x0012dcd0) line 800 + 18 bytes
nsCacheSession::OpenCacheEntry(nsCacheSession * const 0x02e685c0, const char *
0x030e3f10, int 1, int 1, nsICacheEntryDescriptor * * 0x0012dcd0) line 82 + 34 bytes
imgCache::Get(nsIURI * 0x030c2830, imgRequest * * 0x0012df04,
nsICacheEntryDescriptor * * 0x0012de9c) line 190 + 61 bytes
imgLoader::LoadImage(imgLoader * const 0x02e44760, nsIURI * 0x030c2830,
nsILoadGroup * 0x01eeda20, imgIDecoderObserver * 0x030e4260, nsISupports *
0x01f8e9f0, imgIRequest * * 0x02a48b14) line 78 + 40 bytes
nsImageFrame::LoadImage(const nsAString & {...}, nsIPresContext * 0x01f8e9f0,
imgIRequest * * 0x02a48b14) line 1381 + 61 bytes
nsImageFrame::Init(nsImageFrame * const 0x02a48ae0, nsIPresContext * 0x01f8e9f0,
nsIContent * 0x030d19d0, nsIFrame * 0x0294c3c0, nsIStyleContext * 0x02a48aac,
nsIFrame * 0x00000000) line 246 + 49 bytes
nsCSSFrameConstructor::InitAndRestoreFrame(nsIPresContext * 0x01f8e9f0,
nsFrameConstructorState & {...}, nsIContent * 0x030d19d0, nsIFrame * 0x0294c3c0,
nsIStyleContext * 0x02a48aac, nsIFrame * 0x00000000, nsIFrame * 0x02a48ae0) line
6729 + 32 bytes
nsCSSFrameConstructor::ConstructFrameByTag(nsIPresShell * 0x01fa08c0,
nsIPresContext * 0x01f8e9f0, nsFrameConstructorState & {...}, nsIContent *
0x030d19d0, nsIFrame * 0x0294c3c0, nsIAtom * 0x01193cd0, int 3, nsIStyleContext
* 0x02a48aac, nsFrameItems & {...}) line 5019
nsCSSFrameConstructor::ConstructFrameInternal(nsIPresShell * 0x01fa08c0,
nsIPresContext * 0x01f8e9f0, nsFrameConstructorState & {...}, nsIContent *
0x030d19d0, nsIFrame * 0x0294c3c0, nsIAtom * 0x01193cd0, int 3, nsIStyleContext
* 0x02a48aac, nsFrameItems & {...}, int 0) line 7265 + 52 bytes
nsCSSFrameConstructor::ConstructFrame(nsIPresShell * 0x01fa08c0, nsIPresContext
* 0x01f8e9f0, nsFrameConstructorState & {...}, nsIContent * 0x030d19d0, nsIFrame
* 0x0294c3c0, nsFrameItems & {...}) line 7178 + 56 bytes
nsCSSFrameConstructor::ContentAppended(nsCSSFrameConstructor * const 0x01f903e0,
nsIPresContext * 0x01f8e9f0, nsIContent * 0x02e75f80, int 2) line 8182
StyleSetImpl::ContentAppended(StyleSetImpl * const 0x01f88da0, nsIPresContext *
0x01f8e9f0, nsIContent * 0x02e75f80, int 2) line 1099
PresShell::ContentAppended(PresShell * const 0x01fa08c8, nsIDocument *
0x01fbd050, nsIContent * 0x02e75f80, int 2) line 4950 + 46 bytes
nsDocument::ContentAppended(nsDocument * const 0x01fbd050, nsIContent *
0x02e75f80, int 2) line 1604
nsHTMLDocument::ContentAppended(nsHTMLDocument * const 0x01fbd050, nsIContent *
0x02e75f80, int 2) line 1170 + 17 bytes
HTMLContentSink::NotifyAppend(nsIContent * 0x02e75f80, int 2) line 4673
SinkContext::CloseContainer(const nsIParserNode & {...}) line 1598
HTMLContentSink::CloseContainer(HTMLContentSink * const 0x01f71780, const
nsIParserNode & {...}) line 3394 + 18 bytes
CNavDTD::CloseContainer(const nsCParserNode * 0x029b7740, nsHTMLTag
eHTMLTag_center, int 0) line 3550 + 31 bytes
CNavDTD::CloseContainersTo(int 2, nsHTMLTag eHTMLTag_center, int 0) line 3586 +
20 bytes
CNavDTD::CloseContainersTo(nsHTMLTag eHTMLTag_center, int 0) line 3737 + 20 bytes
CNavDTD::HandleEndToken(CToken * 0x029e71b0) line 2014 + 14 bytes
CNavDTD::HandleToken(CNavDTD * const 0x01fa1750, CToken * 0x029e71b0, nsIParser
* 0x01f31a90) line 913 + 12 bytes
CNavDTD::BuildModel(CNavDTD * const 0x01fa1750, nsIParser * 0x01f31a90,
nsITokenizer * 0x01f96cd0, nsITokenObserver * 0x00000000, nsIContentSink *
0x01f71780) line 540 + 20 bytes
nsParser::BuildModel() line 2206 + 34 bytes
nsParser::ResumeParse(int 1, int 1) line 2077 + 11 bytes
nsParser::OnStopRequest(nsParser * const 0x01f31a98, nsIRequest * 0x01fbb070,
nsISupports * 0x00000000, unsigned int 0) line 2710 + 19 bytes
nsDocumentOpenInfo::OnStopRequest(nsDocumentOpenInfo * const 0x01fba840,
nsIRequest * 0x01fbb070, nsISupports * 0x00000000, unsigned int 0) line 248
nsStreamListenerTee::OnStopRequest(nsStreamListenerTee * const 0x01fa0480,
nsIRequest * 0x01fbb070, nsISupports * 0x00000000, unsigned int 0) line 25
nsHttpChannel::OnStopRequest(nsHttpChannel * const 0x01fbb074, nsIRequest *
0x01fbe060, nsISupports * 0x00000000, unsigned int 0) line 2113
nsOnStopRequestEvent::HandleEvent() line 161
nsARequestObserverEvent::HandlePLEvent(PLEvent * 0x02e67694) line 64
PL_HandleEvent(PLEvent * 0x02e67694) line 590 + 10 bytes
PL_ProcessPendingEvents(PLEventQueue * 0x0118b3c0) line 520 + 9 bytes
_md_EventReceiverProc(HWND__ * 0x012808aa, unsigned int 49512, unsigned int 0,
long 18396096) line 1071 + 9 bytes
USER32! 77e71820()
0118b3c0()
changed qa contact to depstein. Note that nsIWebNavigation::LoadURI() and
Reload() are being used in this test case.
QA Contact: mdunn → depstein
This is a cache bug in the base product

*** This bug has been marked as a duplicate of 88447 ***
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → DUPLICATE
.
Status: RESOLVED → VERIFIED
Reopening. Originally this bug covered 2 asserts I found for a url: 1) the 
"accessgranted" one which was duped to 88447; 2) the htmlparser one 
(NS_ENSURE_TRUE msg). Since then, I tried urls from choffman's url list and few 
others. There were additional asserts & crashes found which I'll enter here 
shortly. 
Status: VERIFIED → REOPENED
Resolution: DUPLICATE → ---
Summary: cisco url is causing assertions on load & reload → some urls are causing assertions / crashes on load & reload
Tried out urls in mfcEmbed & testEmbed in 7/18 embedding build. Here's what I 
found:

1) http://www.cisco.com . Might need to load twice to reproduce. Get this 
assertion: NS_ENSURE_TRUE(NS_SUCCEEDED(result)) failed: '(!((result)', file 
/mozilla/htmlparser/src/nsHTMLTokens.cpp line 1974. Can get to site after 
pressing Ignore in the assert msg, but I did get a call stack from 7/13 which is 
listed in the 7/13 entry above.

2) http://al4a.com/links.html . 
http://cards.webshots.com/69278202264 .
Assertion: Onstopdecode called multiple times: '!(mState & onStopDecode)', file 
/mozilla/modules/libprOn/src/imgRequest.cpp line 512 . Can get to site after 
pressing Ignore in the assert msg.

3)http://blackjack02.pogo.com/util/java-vm-test-done.html. 
http://console.popupsponsor.com/media/console.phtml?a_id=3839&creative_type=1&ip
=152.163.195.214&ht .
http://dialpad.com/dialpad/forgot.php3 .
http://play02.pogo.com/arena/silentclosepage.html?site=pogo
Get application error "The instruction at xxx referenced memory at xxx ... The 
memory could not be read." Crashes into debugger, in nsXBLBinding (see call 
stack below).

4) http://britney-spear.com/celeb/home.htm .
http://console.popupsponsor.com/media/console.phtml?a_id=3521&creative_type=2&ip
=205.188.200.166&ht . 
 Closes the browser. looks like window.close() here.

5) http://members2.boardhost.com/n-da-house23/
Get 2 asserts: NS_ENSURE_TRUE(hEntry) failed, file 
/mozilla/docshell/base/nsDocShell.cpp line 3121. Then after pressing Retry, get 
NS_ENSURE_TRUE(NS_SUCCEEDED(rv)) failed, file 
/mozilla/content/base/src/nsDocument.cpp line 2288. Looks like this is related 
to "requesting insecure doc" as that's what msg we get in 6.1

6) http://messenger.msn.com/install/dl.asp?typlang=en-us&typsys=0 .
Assert: Attempt to decrement focus controller's suppression when no suppression 
active: PR_FALSE, file /mozilla/dom/src/base/nsFocusController.cpp line 414 . 
Ignore ==> brings up save dlg. In 6.1 brings up save dlg.

7)http://network.nocreditcard.com/index.ncc .
Only happens for the 1st load, can't reproduce even after relaunch.
Assert: not a percent value: 'mUnit == eStyleUnit_Percent', file 
/mozilla/dist/include/nsStyleCoord.h line 159
Ignore ==> navigates to the web site.

8) 
http://nitrous.exitfuel.com/?BPROGRAM=EF1&LINKIN=jester&REF=http://www.found404.
com/affiliate2/pc40 . 
http://nitrous.exitfuel.com/?BPROGRAM=EF1&LINKIN=wplanet&REF=http://www.wrestlin
gplanet.com/headlin .
Assert: NS_ENSURE_TRUE(context) failed: 'context', file 
/mozilla/content/base/src/nsGenericElement.cpp line 2654. Pressing Ignore does 
nothing, pressing Retry ==> #3 (can't read memory). App window becomes minimized 
and can't be closed. In 6.1, minimized.

9) probably related to the cache bug (88447) which was marked fix.
http://tlc.discovery.com:4000/mb/user/message.html?ct=2662947&NoFrames=1&Message
=11191
Assert: oops .. badflags: 'entry->IsAllowedInMemory(), file 
/mozilla/netwerk/cache/src/nsCacheService.cpp line 939

I'll test out www.xxx.com web sites later.

call stack for #3:

nsXBLBinding::InitClass(nsXBLBinding * const 0x01efbee0, const nsCString & 
{...}, nsIScriptContext * 0x00000000, nsIDocument * 0x02eaba10, void * * 
0x0012e678, void * * 0x0012e680) line 1566 + 3 bytes
nsXBLBinding::InstallProperties(nsXBLBinding * const 0x01efbee0) line 1100 + 45 
bytes
nsXBLBinding::InstallProperties(nsXBLBinding * const 0x01ef8350) line 1066
nsXBLService::LoadBindings(nsXBLService * const 0x01f766c0, nsIContent * 
0x01ef5e40, const nsAString & {...}, int 0, nsIXBLBinding * * 0x0012f420, int * 
0x0012f40c) line 725
nsCSSFrameConstructor::ConstructFrameInternal(nsIPresShell * 0x02e32180, 
nsIPresContext * 0x02ec5c30, nsFrameConstructorState & {...}, nsIContent * 
0x01ef5e40, nsIFrame * 0x0298b24c, nsIAtom * 0x0118b1d0, int 7, nsIStyleContext 
* 0x0298b68c, nsFrameItems & {...}, int 0) line 7217 + 73 bytes
nsCSSFrameConstructor::ConstructFrame(nsIPresShell * 0x02e32180, nsIPresContext 
* 0x02ec5c30, nsFrameConstructorState & {...}, nsIContent * 0x01ef5e40, nsIFrame 
* 0x0298b24c, nsFrameItems & {...}) line 7178 + 56 bytes
nsCSSFrameConstructor::CreateAnonymousFrames(nsIPresShell * 0x02e32180, 
nsIPresContext * 0x02ec5c30, nsFrameConstructorState & {...}, nsIContent * 
0x02eb16f0, nsIDocument * 0x02eaba10, nsIFrame * 0x0298b24c, nsFrameItems & 
{...}) line 5298
nsCSSFrameConstructor::BuildGfxScrollFrame(nsIPresShell * 0x02e32180, 
nsIPresContext * 0x02ec5c30, nsFrameConstructorState & {...}, nsIContent * 
0x02eb16f0, nsIDocument * 0x02eaba10, nsIFrame * 0x0298b0f8, nsIStyleContext * 
0x0298b1b4, int 1, nsIFrame * & 0x0298b24c, nsFrameItems & {...}, nsIFrame * 
0x0298b4bc) line 6172
nsCSSFrameConstructor::BeginBuildingScrollFrame(nsIPresShell * 0x02e32180, 
nsIPresContext * 0x02ec5c30, nsFrameConstructorState & {...}, nsIContent * 
0x02eb16f0, nsIStyleContext * 0x0298b1b4, nsIFrame * 0x0298b0f8, nsIAtom * 
0x01187d10, nsIDocument * 0x02eaba10, int 1, nsIFrame * & 0x0298b134, 
nsCOMPtr<nsIStyleContext> & {...}, nsIFrame * & 0x00000000, nsIFrame * 
0x00000000) line 5
nsCSSFrameConstructor::ConstructRootFrame(nsCSSFrameConstructor * const 
0x02e346e0, nsIPresShell * 0x02e32180, nsIPresContext * 0x02ec5c30, nsIContent * 
0x02eb16f0, nsIFrame * & 0x00000000) line 3857
StyleSetImpl::ConstructRootFrame(StyleSetImpl * const 0x02e347a0, nsIPresContext 
* 0x02ec5c30, nsIContent * 0x02eb16f0, nsIFrame * & 0x00000000) line 1084 + 39 
bytes
PresShell::InitialReflow(PresShell * const 0x02e32180, int 11340, int 6315) line 
2607
HTMLContentSink::StartLayout() line 3862
HTMLContentSink::OpenBody(HTMLContentSink * const 0x02eb04a0, const 
nsIParserNode & {...}) line 3148
CNavDTD::OpenBody(const nsCParserNode * 0x029750d8) line 3151 + 31 bytes
CNavDTD::OpenContainer(const nsCParserNode * 0x029750d8, nsHTMLTag 
eHTMLTag_body, int 1, nsEntryStack * 0x00000000) line 3405 + 12 bytes
CNavDTD::HandleDefaultStartToken(CToken * 0x02961d38, nsHTMLTag eHTMLTag_body, 
nsCParserNode * 0x029750d8) line 1337 + 20 bytes
CNavDTD::HandleStartToken(CToken * 0x02961d38) line 1746 + 22 bytes
CNavDTD::HandleToken(CNavDTD * const 0x02e47ac0, CToken * 0x02961d38, nsIParser 
* 0x02eab8a0) line 910 + 12 bytes
CNavDTD::BuildModel(CNavDTD * const 0x02e47ac0, nsIParser * 0x02eab8a0, 
nsITokenizer * 0x02e476a0, nsITokenObserver * 0x00000000, nsIContentSink * 
0x02eb04a0) line 540 + 20 bytes
nsParser::BuildModel() line 2218 + 34 bytes
nsParser::ResumeParse(int 1, int 0) line 2084 + 11 bytes
nsParser::OnDataAvailable(nsParser * const 0x02eab8a8, nsIRequest * 0x02e79a20, 
nsISupports * 0x00000000, nsIInputStream * 0x02e46170, unsigned int 0, unsigned 
int 150) line 2692 + 19 bytes
nsDocumentOpenInfo::OnDataAvailable(nsDocumentOpenInfo * const 0x02e22cc0, 
nsIRequest * 0x02e79a20, nsISupports * 0x00000000, nsIInputStream * 0x02e46170, 
unsigned int 0, unsigned int 150) line 235 + 46 bytes
nsStreamListenerTee::OnDataAvailable(nsStreamListenerTee * const 0x02e461c0, 
nsIRequest * 0x02e79a20, nsISupports * 0x00000000, nsIInputStream * 0x02e27b20, 
unsigned int 0, unsigned int 150) line 56 + 51 bytes
nsHttpChannel::OnDataAvailable(nsHttpChannel * const 0x02e79a24, nsIRequest * 
0x02e27c10, nsISupports * 0x00000000, nsIInputStream * 0x02e27b20, unsigned int 
0, unsigned int 150) line 2150 + 57 bytes
nsOnDataAvailableEvent::HandleEvent() line 175 + 70 bytes
nsARequestObserverEvent::HandlePLEvent(PLEvent * 0x02e79814) line 64
PL_HandleEvent(PLEvent * 0x02e79814) line 590 + 10 bytes
PL_ProcessPendingEvents(PLEventQueue * 0x0117b740) line 520 + 9 bytes
_md_EventReceiverProc(HWND__ * 0x002503e4, unsigned int 49429, unsigned int 0, 
long 18331456) line 1071 + 9 bytes
USER32! 77e71820()
0117b7
Severity: normal → major
A few changes with the above urls in the 7/19 embedding build:
* cisco url is working
* The urls grouped in #3 above now just shutdown the browser, just like in #4.
e.g. http://blackjack02.pogo.com/util/java-vm-test-done.html . Looks like
another window.close prob.
* http://members2.boardhost.com/n-da-house23/ is working fine (#5 above).
* http://tlc.discovery.com:4000/mb/user/message.html?ct=2662947&NoFrames=1&Message
is working (#9 above)


The "not a percent value" assertions are being taken care of in bug 88172.
Depends on: 88172
I tried out the www urls on the list. Some more urls causing problems:
* This url is causing the problem in the htmlparser (#1 above):
http://www.listin.com.do/antes/110601/welcome.htm
* This one results in different asserts when I loaded it on different occassions:
http://www.google.com/search?q=livin%27+large+(warez)&hl=en&safe=off&start=30&sa=N
(one assert is the htmlparser one, another is the OnStopDecode (#2 above))
* Also resulting in onStopDecode msgs were:
http://www.airliners.net/search/photo.search
http://www.officemax.com/max/solutions/product/prodBlock.jsp?BV_UseBVCookie=yes&expansionOID=-53687
* These are causing the nsGenericElement prob (#8 above):
http://www.apple.com (intermittent)
http://www.pch.com/popover/popover.html
* This caused the focus prob (#6 above):
http://www.webgrafx-fx.com/community/rules.shtml
* This one caused the prob in nsDocShell.cpp line 3121 (#5 above). To reproduce
you might need to quit, relaunch, then load url:
http://www.mundolatino.com/honduras/honwin01.htm
* Enter this url, then press OK at the warning msg:
http://www.newlolitas.com/ts.htm
This results in assert: NS_ENSURE_TRUE(mContentViewer) failed: mContentViewer,
file /mozilla/docShell/base/nsDocShell.cpp line 2332.
* These shut down the browser (#4 above):
http://www.cyberporno.com/bb.html?ip=3030004120
http://www.easysex.com/forfree/bb.html?ip=M517
* another one causing the "not a percent" assert:
http://www.goamerica.net/beta/mobileoffice/pro_ser/branding.html (see 88172)
* http://www.zdnet.com/downloads/mp3.html
This causes assert: leaf without container: 'mCurrentContext->mStackPos > 0',
file /mozilla/content/html/document/src/nsHTMLContentSink.cpp line 4919





per WRMB 7979, marking topembed for keyword. This is a tracking bug for crashes
& assertions in mozilla.exe and mfcembed. most of these links are still causing
probs (www.cisco.com is OK now). If need be, I can create some dependency bugs
for the specific crash and assert types (see above).
Keywords: topembed
Summary: some urls are causing assertions / crashes on load & reload → some urls are causing crashes or asserts on load & reload
put WRMB in the subject. From WRMB 7979.
Summary: some urls are causing crashes or asserts on load & reload → WRMB: some urls are causing crashes or asserts on load & reload
bug 94241 covers the onStopDecode problem (#2 above).
Depends on: 94241
bug 94656 covers session history entry (hEntry) assert from #5 above.
bug 94819 deals with the nsGenericElement one (#8 above)
Depends on: 94819
bug 94824 deals with 'leaf without container' assert above.
Depends on: 94824
bug 94926 now covers the hEntry problem (instead of bug 94656).
Depends on: 94926
No longer depends on: 88172
Assigning this bug to me. It is a meta-bug for a bunch of crashers.
Assignee: adamlock → barrowma
Status: REOPENED → NEW
Target Milestone: --- → mozilla0.9.4
this bug will now only address the crashes in the nightly builds. See my 8/17
entry for urls still doing this. I removed references to assertions in the
summary and removed bug dependencies (there are individual bugs addressing the
asserts).
No longer depends on: 94241, 94824, 94926
Summary: WRMB: some urls are causing crashes or asserts on load & reload → WRMB: some urls are causing crashes when loading
Of the following URLs which "shut down the browser", on MFC Embed 0.9.2
08/22/2001, none of them actually crash it - they merely close the window.  In
IE, the user is presented with a dialog saying that the page has asked to close
the window, giving the user the ability to say no.  I assume that IE has some
rules about when a page is allowed to close a window without causing the dialog
to appear, since a page should be able to close a popup it opened.

* http://blackjack02.pogo.com/util/java-vm-test-done.html
* http://dialpad.com/dialpad/forgot.php3
* http://play02.pogo.com/arena/silentclosepage.html?site=pogo
* http://www.pch.com/popover/popover.html


These two URLs resize the window and try to hide it offscreen, I think.  The
window is not visible on the screen in IE, but still appears in the task bar and
is maximizable.  In MFC Embed, the window remains visible but it becomes very small.

* http://console.popupsponsor.com/media/console.phtml?a_id=3839&creative_type=1&ip
* http://nitrous.exitfuel.com/?BPROGRAM=EF1&LINKIN=wplanet&REF=http://www.wrestlin

I think we are doing the right thing for these sites, though we may want to
investigate if throwing a warning dialog like IE does is a good idea.
Status: NEW → ASSIGNED
Barrowman - Is this is a must fix for the branch, please mark as nsbranch+.
Otherwise, pls move it out to TM0.9.5.
changed summary to reflect this is now covering window closer bugs. One solution
is to post a Yes/No prompt before window is closed. This is what IE does. For
the 2 urls minimizing the window, I'll enter another bug for that.
Summary: WRMB: some urls are causing crashes when loading → WRMB: some urls are closing windows (Yes/No prompt before closing?)
Moving out to 0.9.5.
Target Milestone: mozilla0.9.4 → mozilla0.9.5
Blocks: 97688
Just for the sake of more information Nav4 also sometimes popped up a dialog to
query if the user wished a window to be closed via JavaScript.  Nav4 decided
whether or not to pop up the dialog based on whether or not the window had been
opened via JavaScript in the first place.  Windows opened by JS could be closed
by JS without a question.  Any other windows popped up the dialog.  I'm not sure
if we have easy access to whether a window was JS created or not in mozilla but
if we do we might consider the same logic.
should we close this bug and create a new one for confirmation dialog?
Jud - I think that would be the right thing to do.  I think the 4.x behavior is
a reasonable target.
  See the  five line comment at GlobalWindowImpl::Close (nsGlobalWindow.cpp line 
2415 at the moment). That comment dates from 1999 and refers to bug 9703. I don't 
remember what was the promised better means to decide whether a window could be 
closed without asking.
  It's tough to decide which windows were opened by application script and which 
were opened by website script. There is a heuristic for deciding whether a window 
was a popup used in determining whether its persistent size/position attributes 
should affect subsequent browser windows. Lacking something better, we could 
reasonably crib that for Close(), I think.
  About IE's treatment for attempts to move windows offscreen (making them 
invisible but leaving them in the taskbar), I prefer our treatment. The taskbar 
doesn't translate well to other platforms, anyway.
Todd Pringle is cool w/ mimic'ing 4.x handling. Let's shoot for using the
persistence semantics to trigger a dialog in this case. This should bake for
awhile on the trunk though once we have a solution (read that as, this might not
make 0.9.4)

-> dan
Assignee: barrowma → danm
Status: ASSIGNED → NEW
Keywords: topembed
Target Milestone: mozilla0.9.5 → mozilla0.9.6
adding topembed and bugscape ref
Keywords: topembed
Whiteboard: [bugscape: 7979]
Blocks: 64833
Severity: major → enhancement
Keywords: topembed
Target Milestone: mozilla0.9.6 → mozilla0.9.7
Although this may seem like yet another gratuitous make-it-a-pref request ...
I'd like to request that this be controllable through a pref. Some tests 
(notably the page load times on btek.mcom.com, and the quick-and-dirty startup 
test) have come to depend on window.close unilaterally closing the window. 

It's fine to implement this for end users that restricts this by default; I 
just want a way to override it. (Actually I think it is a good idea 
to prevent a remote web site from potentially shutting down the application).
Target Milestone: mozilla0.9.7 → mozilla0.9.8
Target Milestone: mozilla0.9.8 → ---
Target Milestone: --- → Future
removing myself from the cc list
QA Contact: depstein → carosendahl
Assignee: danm.moz → nobody
QA Contact: carosendahl → apis
Marking a bunch of bugs in the "Embedding: APIs" component INCOMPLETE in preparation to archive that component. If I have done this incorrectly, please reopen the bugs and move them to a more correct component as we don't have "embedding" APIs any more.
Status: NEW → RESOLVED
Closed: 23 years ago8 years ago
Resolution: --- → INCOMPLETE
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: