8389 - [LAYER][CRASH] DOGFOOD AppRunner crashes when it hits page with LAYER tag (internal netscape site w3) - nsJSUtils.cpp nsJSUtils::nsConvertObjectToJSVal

Status: VERIFIED INVALID

(Tech Evangelism Graveyard :: English US, defect, P1)

Description

[chris hofmann]

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

Comment 1

[leger]

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

Comment 2

[chris hofmann]

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

Comment 3

[vidur (gone)]

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.

Comment 4

[ekrock's old account (dead)]

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.

Comment 5

[ekrock's old account (dead)]

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

Comment 6

[Jay Patel [:jay]]

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

Comment 7

[Jay Patel [:jay]]

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

Comment 8

[Jon Granrose]

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?

Comment 9

[Jon Granrose]

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?

Comment 10

[ekrock's old account (dead)]

Sent email to [e-mail] and [e-mail] 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)
}

Comment 11

[ekrock's old account (dead)]

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.)

Comment 12

[rickg]

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.

Comment 13

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

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.

Comment 14

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

Crashes are all M11/P1/critical.

Comment 15

[vidur (gone)]

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.

Comment 16

[harishd]

Checked in a Fix.

Comment 17

[Prashant Desale]

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

Comment 18

[ekrock's old account (dead)]

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.

Comment 19

[Blake Ross]

Adding crash keyword

Comment 20

[ekrock's old account (dead)]

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.

Comment 21

[Zach Lipton [:zach]]

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

Sorry about the spam

zach

Comment 22

[Blake Ross]

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

Comment 23

[Blake Ross]

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

Comment 24

[Blake Ross]

re-resolving as INVALID

Comment 25

[Blake Ross]

vrfy invalid

Comment 26

[Bob Clary [:bc] (inactive)]

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