got have some way to get to the phonebook... right now I get Call Stack: (Signature = nsJSUtils::nsConvertObjectToJSVal a309d496) nsJSUtils::nsConvertObjectToJSVal [d:\builds\seamonkey\mozilla\dom\src\base\nsJSUtils.cpp, line 133] GetHTMLLayerElementProperty [d:\builds\seamonkey\mozilla\dom\src\html\nsJSHTMLLayerElement.cpp, line 211] js_GetProperty [d:\builds\seamonkey\mozilla\js\src\jsobj.c, line 1695] js_Interpret [d:\builds\seamonkey\mozilla\js\src\jsinterp.c, line 2164] js_Invoke [d:\builds\seamonkey\mozilla\js\src\jsinterp.c, line 676] js_Interpret [d:\builds\seamonkey\mozilla\js\src\jsinterp.c, line 2207] js_Invoke [d:\builds\seamonkey\mozilla\js\src\jsinterp.c, line 676] js_CallFunctionValue [d:\builds\seamonkey\mozilla\js\src\jsinterp.c, line 741] JS_CallFunctionValue [d:\builds\seamonkey\mozilla\js\src\jsapi.c, line 2556] nsJSEventListener::HandleEvent [d:\builds\seamonkey\mozilla\dom\src\events\nsJSEventListener.cpp, line 98] nsEventListenerManager::HandleEvent [d:\builds\seamonkey\mozilla\layout\events\src\nsEventListenerManager.cpp, line 952] GlobalWindowImpl::HandleDOMEvent [d:\builds\seamonkey\mozilla\dom\src\base\nsGlobalWindow.cpp, line 2381] nsWebShell::OnEndDocumentLoad [d:\builds\seamonkey\mozilla\webshell\src\nsWebShell.cpp, line 2596] nsDocLoaderImpl::FireOnEndDocumentLoad [d:\builds\seamonkey\mozilla\webshell\src\nsDocLoader.cpp, line 848] nsDocLoaderImpl::LoadURLComplete [d:\builds\seamonkey\mozilla\webshell\src\nsDocLoader.cpp, line 1022] nsDocumentBindInfo::OnStopBinding [d:\builds\seamonkey\mozilla\webshell\src\nsDocLoader.cpp, line 1552] OnStopBindingProxyEvent::HandleEvent [d:\builds\seamonkey\mozilla\network\module\nsNetThread.cpp, line 594] StreamListenerProxyEvent::HandlePLEvent [d:\builds\seamonkey\mozilla\network\module\nsNetThread.cpp, line 474] PL_HandleEvent [plevent.c, line 492] PL_ProcessPendingEvents [plevent.c, line 453] _md_EventReceiverProc [plevent.c, line 881] KERNEL32.DLL + 0x3663 (0xbff73663) jsval* aReturn) 129 vidur 1.1 { 130 // get the js object\n" 131 if (aSupports != nsnull) { 132 nsIScriptObjectOwner *owner = nsnull; 133 if (NS_OK == aSupports->QueryInterface(kIScriptObjectOwnerIID, (void**)&owner)) { 134 JSObject *object = nsnull; 135 nsIScriptContext *script_cx = (nsIScriptContext *)JS_GetContextPrivate(aContext); 136 if (NS_OK == owner->GetScriptObject(script_cx, (void**)&object)) { 137 vidur 1.2 // set the return value 138 *aReturn = OBJECT_TO_JSVAL(object); 139 vidur 1.1 } 140 NS_RELEASE(owner); 141 } 142 NS_RELEASE(aSupports); 143 } 144 else { 145 *aReturn = JSVAL_NULL; 146 waterson 1.10 } 147 } 148

We should fix this for M8, but would not hold M7 at this point. Setting to M8.

the stack look like the same as the one generated when visiting http://spaceflight.nasa.gov/ in bug 7590 , dup?

Well, the site doesn't crash, but it isn't happy since it uses layers. Assigning this one to Eric Krock, since he's dealing with informing customers (internal ones in this case) that layers are going away.

Setting to M10 as getting this fixed is a high priority for internal usage by beta; other LAYER bugs will be assigned to M15 for as-time-allows evangelism.

See also #1981, related report on http://w3/.

I've been crashing at http://w3 on win98 and mac 8.5.1 (Linux just keeps trying to load the page, but doesn't crash) here is the stack trace from my talkback report: Trigger Type: Program Crash Trigger Reason: Access violation Call Stack: (Signature = JSDOM.DLL + 0x78fa (0x606f78fa) 8b69cd36) JSDOM.DLL + 0x78fa (0x606f78fa) JSDOM.DLL + 0x1c0ff (0x6070c0ff) JS3250.DLL + 0x1c7ad (0x606cc7ad) JS3250.DLL + 0x16e00 (0x606c6e00) JS3250.DLL + 0x13536 (0x606c3536) JS3250.DLL + 0x172de (0x606c72de) JS3250.DLL + 0x13536 (0x606c3536) JS3250.DLL + 0x1366a (0x606c366a) JS3250.DLL + 0x39e4 (0x606b39e4) JSDOM.DLL + 0x160f5 (0x607060f5) RAPTORHTML.DLL + 0x8a6ca (0x6031a6ca) JSDOM.DLL + 0x6601 (0x606f6601) RAPTORWEB.DLL + 0x5f06 (0x60945f06) RAPTORWEB.DLL + 0x20ca (0x609420ca) RAPTORWEB.DLL + 0x22a4 (0x609422a4) RAPTORWEB.DLL + 0x2a21 (0x60942a21) NETLIB.DLL + 0x2a74 (0x607a2a74) NETLIB.DLL + 0x28ff (0x607a28ff) PLDS3.DLL + 0x18ee (0x608a18ee) PLDS3.DLL + 0x186a (0x608a186a) PLDS3.DLL + 0x1b18 (0x608a1b18) KERNEL32.DLL + 0x363b (0xbff7363b) KERNEL32.DLL + 0x242e7 (0xbff942e7) 0x00638c16

I was using the latest builds 1999071308 for Linux, 1999071310 for win32 and 1999071309 for mac

I just ran into this myself with the M8 build on my omnibook 5700 running NT 4.0 sp3. I've been asked about this by several of my fellow TSEs who I've announced M8 to to start to get familiar with it. definitely a dogfood bug, any chance we can get this moved up to m9?

This is also a crash and I don't care if we aren't going to be using layers or not, it shouldn't crash when it finds one. can we get this assigned to an engineer as well?

Sent email to kimf@netscape.com and tomm@netscape.com re: need for a fix. *** Please forward this problem report to IS management so a fix can be scheduled and staffed. *** http://w3/ doesn't work on Navigator 5. The problem is that it uses the LAYER tag (which is support for static positioning only in Nav5) as well as the Nav4 Layer DOM API (which does not work in Nav5). http://w3/ needs to be fixed by Navigator 5 beta so that internal users can use it and get work done. - see http://sites.netscape.com/ekrock/answers.html for a list of resources for learning Nav5 DOM. In particular, see: a) http://devedge.netscape.com/docs/examples/javascript/browser_type.html for a Nav5-aware client sniffer b) see http://sites.netscape.com/ekrock/answers.html#dom for info about the Nav5 W3C DOM c) see http://dmoz.org/Computers/Programming/Languages/JavaScript/W3C_DOM/ for learning resources d) see http://dmoz.org/Computers/Programming/Languages/JavaScript/W3C_DOM/Sample_Code/s tyle/ for examples of setting style properties from the W3C DOM, which is what you need to do Nav4-dependent sections of code which need to be upgraded to check userAgent and fork to use W3C DOM code on Nav5: change to use document.getElementByID() to get element and then use the DOM2 CSS API to set visibility property: function showIntranet() { document.phone_graphic.visibility="hide"; document.phone_input.visibility="hide"; document.intranet_graphic.visibility="show"; document.intranet_input.visibility="show"; } function hideFocaler() { document.Focal.visibility="hide"; document.whatsnew.visibility="hide"; } function Focaler() { document.Focal.visibility="show"; document.whatsnew.visibility="show"; // timVar = setTimeout("hideFocaler()",30000) } function hideFocaler2() { document.Focal2.visibility="hide"; document.whatsnew.visibility="hide"; } function Focaler2() { document.Focal2.visibility="show"; document.whatsnew.visibility="show"; // timVar = setTimeout("hideFocaler2()",90000) } function hideUpgrader() { document.Upgrade.visibility="hide"; } function countDown() { document.Upgrade.visibility="show"; timVar = setTimeout("hideUpgrader()",60000) }

Reproduced crash behavior in M9 on WinNT 4.0 SP3. There are two issues here: 1) the internal IS site http://w3/ needs to be upgraded to stop using LAYER. I've notified them of this and they're aware of the need to fix by beta, so consider this issue closed for our purposes; it's up to them. 2) However, as granrose noted, Nav5 definitely SHOULD NOT CRASH when it hits a page with LAYER, whether or not it supports the LAYER tag (final status of that currently under discussion on n.p.m.mozilla). So, I'm reassigning this bug to rickg. From now on this bug should be considered a browser crash bug for resolution by engineering, not a we-gotta-upgrade-a-site LAYER tracking bug. (Consider that part of the issue closed.)

Vidur -- I'm giving this to you as a placeholder (I can't remember if you get layer issues or if EricK does). Nonetheless, there'a s crash involved and JS in nearby, so you may want to take a glance.

Troy, when we turn layers off completely, can you let us know so we can retest this bug? I think that might change the landscape significantly. We need to fix this class of crashes by beta, I think.

Crashes are all M11/P1/critical.

The page doesn't crash anymore (a result of a prior layers-related checkin). However, it hits a meta http-equiv refresh inside a NOLAYER element and reloads infinitely. Assigning to harishd to deal with the reloading problem (he has a fix). The resultant gets laid out crappily because of its use of layers, but hopefully the page content will change soon.

Checked in a Fix.

I don't see any crash now. Marking verified.

Moving all [LAYER] bugs to Evangelism component for tracking and open-source evangelism by mozilla community members of sites that need to upgrade to support web standards such as HTML 4.0 (instead of LAYER/ILAYER) and the W3C DOM (instead of Nav4 document.layers[] or IE document.all()). Sites should be lobbied to do the upgrade using the email templates that are linked to from http://www.mozilla.org/newlayout/bugathon.html#layerbugs . When a site's owner has confirmed receipt of the message requesting an upgrade, the bug should be marked with the keyword evangelized to indicate that evangelism for that bug is complete. When the site finishes the upgrade and supports standards, the bug should be closed.

Adding crash keyword

Closing all Evangelism bugs where no evangelism is needed because page has been fixed, site is internal to Netscape, report is a DUP, or bug report is no longer appropriate for evangelism for any other reason.

SPAM:Changing QA contact on 111 evang bugs as I am now the new QA contact for this component. Sorry about the spam zach

Reassigning Evangelism bugs to me, the component's new owner. I would like to take this opportunity to thank nobody@mozilla.org for all of his dedication, contributions, and hard work, and wish him luck at his new job. Thanks, nobody.

workaround bugzilla problem that caused a bunch of evangelism bugs to be NEW/INVALID, NEW/FIXED, NEW/WORKSFORME or NEW/DUPLICATE

re-resolving as INVALID

vrfy invalid

All Evangelism Bugs are now in the Product Tech Evangelism. See bug 86997 for details.