Mozilla crashes after clicking Page Info -> Tab "Links"; trunk [@ js_GetProperty] (only if java is installed)




17 years ago
4 years ago


(Reporter: schnirbbel, Assigned: sicking)


({crash, regression, topcrash-})

Dependency tree / graph

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [needs answer to comment 47 or should be closed][needs testcase], crash signature, )


(3 attachments, 1 obsolete attachment)

Open the page (they do run a nice Benchmark there with chessprograms), using an
applet to show the games online in realtime.
Mozilla always crashed with the nightly build from yesterday, and with the one
from today (2002062713), after rightclicking mouse -> Page Info -> switching to
Tab "Links".
Gives an GPF, and under Details shows "JS3250.DLL", so it might be related to
Reassigning to Browser-General until we can get a stack trace.
Often the top of stacks refer to JS3250.DLL, but the actual error
usually occurs lower down in the stack - would it be possible for you to download a
Talkback-enabled build? (see 

If you can get a Talkback build to crash, please fill out a
Talkback report for us. Then after Talkback sends the crash, 
run "(install_directory)/mozilla/components/talkback.exe" and 
post the Talkback ID(s) into this bug in the "Additional Comments"
box above (then hit the "Commit" button). That way we can look up
the stack traces that you generated. Thanks -

Also: is it only on this page that you get the crash you describe
above? Or can you crash like that on other Web pages, too?
Assignee: rogerl → Matti
Component: JavaScript Engine → Browser-General
QA Contact: pschwartau → imajes-qa
Note: I have an build from 10 days ago (20020617xx).
When I try the steps to reproduce, I see two errors in 
Tools > Web Development > JavaScript Console:

Error: aDocument.hasAttributeNS is not a function
Source File: chrome://navigator/content/pageInfo.js
Line: 539

Error: uncaught exception: [Exception... "'[JavaScript Error: 
"aDocument.hasAttributeNS is not a function" {file: 
"chrome://navigator/content/pageInfo.js" line: 539}]' when calling method: 
[nsIDOMNodeFilter::acceptNode]"  nsresult: "0x80570021 
chrome://navigator/content/pageInfo.js :: grabAllXLinks :: line 550"  data: yes]

However, I do not crash -
Keywords: crash
Posted file backtrace
a 12 h. old CVS, Linux (non-debug, with symbols) seems to crash here:

#0  0x4009b92c in js_GetProperty () from /
#1  0x4008eea2 in js_Interpret () from
#2  0x40087f77 in js_Invoke () from
#3  0x40595595 in nsXPCWrappedJSClass::CallMethod () from
#4  0x40591413 in nsXPCWrappedJS::CallMethod () from
#5  0x4018444e in PrepareAndDispatch () from
#6  0x401844b2 in nsXPTCStubBase::Stub3 () from
#7  0x40ed5e47 in nsTreeWalker::TestNode () from
#8  0x40ed5c8e in nsTreeWalker::ChildOf () from
#9  0x40ed54b2 in nsTreeWalker::FirstChildOf () from
#10 0x40ed5d31 in nsTreeWalker::ChildOf () from
#11 0x40ed54b2 in nsTreeWalker::FirstChildOf () from
with an official trunk linux 20020617xx i see the same as in comment 2
In addition, the "links" tab is blank
OS: Windows 98 → All
ha, i watch this match since the last 2 days and also the people in the german 
mozilla channel but i never clicked on PI :-)

confirming with my 10min old CVS optimized and 3days old debug build
Ever confirmed: true
Posted file win2k stack trace
Phil : Do you know if this is Dom0 ?
Crashed for me, although it thought about it for a while. Win98SE build

Talkback ID #TB7786295G

Severity of this bug needs to be changed. "Normal" isn't used for browser crashes.
caillon means that this could be DOM Core
Assignee: Matti → jst
Severity: normal → critical
Component: Browser-General → DOM Core
QA Contact: imajes-qa → desale
Note: I looked up Talkback ID #TB7786295G (see Comment #7).

It has the same stack trace that Matti provided in Comment #6,
and R.K.Aa provided in Comment #3 -
i saved this page because it will possible disappear after the benchmark is

This doesn't crash if the java applet can't be loaded..
Summary: Mozilla crashes after clicking Page Info -> Tab "Links" → Mozilla crashes after clicking Page Info -> Tab "Links" [in js_GetProperty]
Installed Mozilla Trunk 2002062808 with Talkback enabled. 
The TB-ID is: TB7817395H. Maybe the stack gives a hint.
The error still occurs on that page, but i have been able to reproduce this on 
another page.
Created a testpage with an simple applet, Mozilla crashed again after PI->Links.
I used old applet-tag style, not the object-tag. Maybe that could be a reason,
but i did not look at the source at thanks for providing a Talkback stack trace!
I looked up your Talkback ID TB7817395H. It shows the same stack trace
as those above, so that's good.

Thank you for testing the effect of Java applets on this problem.
If you have a reduced testcase, you can attach it to this bug
via the "Create a New Attachment" link above. That would be great -
I created a pure and simple html-testpage, it is online under:
The applet itself doesn't do anything usefull, but it is enough for testing 
purpose. Inspected the source of heise, they use the old applet-tag as well 
(maybe for NS 4 User).
Hope, that is helpfull.
QA Contact: desale → stummala
js_GetProperty is a topcrash on the trunk.  Added topcrash to keywords and
modified summary for tracking.
Keywords: topcrash
Summary: Mozilla crashes after clicking Page Info -> Tab "Links" [in js_GetProperty] → Mozilla crashes after clicking Page Info -> Tab "Links"; trunk [@ js_GetProperty]
Doesn't crash with build 2002071008 - Win XP.

Weird ?!
Yes, somehow strange (arrgh, what the heck - cant use cursor-keys in this textfield 
to move back and forward, is this normal?)
The same build 2002071008 still crashes on my machine.
The URL is no longer valid since the chess benchmark is finished and there is no
adding NEW URL from the Reporter.
I think this crash is caused by an incorrect value being sent for JSProperty*.

Not sure what value should actually be sent here :-(
*** Bug 156757 has been marked as a duplicate of this bug. ***
OK.  Do we have a regression date?  I suspect this may be caused by the fix for
bug 59686...

The pageinfo code is trying to call getAttributeNS on the domnode, and I bet the
screwed-up proto chain interferes somehow...
Keywords: regression
Summary: Mozilla crashes after clicking Page Info -> Tab "Links"; trunk [@ js_GetProperty] → Mozilla crashes after clicking Page Info -> Tab "Links"; trunk [@ js_GetProperty] (only if java is installed)
*** Bug 157968 has been marked as a duplicate of this bug. ***
Posted patch workaround (obsolete) — Splinter Review
this "fixes" the crash by not calling hasAttributeNS on applet elements. Since
it is a wallpaper fix i would say that we should only land this on the branch
and try to fix it appropriatly on the trunk
Comment on attachment 92302 [details] [diff] [review]

sr=jst, but please rename aDocument to aElement since we *know* we're not
dealing with a document here.
Attachment #92302 - Flags: superreview+
Comment on attachment 92302 [details] [diff] [review]

Attachment #92302 - Flags: review+
->sicking to checkin
Assignee: jst → sicking
Comment on attachment 92302 [details] [diff] [review]

obsoleting, this one didn't make it to the branch
Attachment #92302 - Attachment is obsolete: true
dupping this to it's real problem

*** This bug has been marked as a duplicate of 59686 ***
Closed: 17 years ago
Resolution: --- → DUPLICATE
Comment on attachment 92302 [details] [diff] [review]

trying for branch again...
Attachment #92302 - Attachment is obsolete: false
Marking adt1.0.1-.  Since this is branch only it'll be fixed in the next release.
Keywords: adt1.0.1adt1.0.1-
Comment on attachment 92302 [details] [diff] [review]

Attachment #92302 - Attachment is obsolete: true
*** Bug 167356 has been marked as a duplicate of this bug. ***
Reopening and marking dependency so we can work around this for major releases
like 1.1 and 1.2 and so forth in the future (since bug 59686 is not likely to be
fixed any time soon).
Depends on: 59686
Resolution: DUPLICATE → ---
No longer depends on: 59686
Looks like there was a midair collision that removed the dependancy.....fixing.
Depends on: 59686
MacsBug stdlog from testcase in comment #13.
Somehow, my additional comments didn't get added to my attachment.  Been a while
since I posted here.

Anyway, Mozilla crashed very nicely on Mac OS 9.2.2 running on an iMac DV G3/400
with 192 MB RAM.  Build was trunk build 2002101508.  Need more info?  Feel free
to type.
Steps taken

1 Open the page and 
2 Select menu option "view page info 
3 Click the links button
4 Everything works as expected

The bug doesn't appear to be there on Linux build 20021214 and W2K build 1.3A 
All incidents in the database for this stack sig are from older builds.
Marking topcrash-.  Maybe this should be marked fixed?
Keywords: topcrashtopcrash-
no, afaik this still crashes
I was unable to reproduce this bug in the Nightly Build dated 2002.02.02,
running on Windows 2000.
WFM as well, xp pro sp1. Don't know what fixed this but the problem seems to be
solved in the recent nightlies.
This is still not fixed. The reason it doesn't crash is because a workaround was
landed. The underlying crash is still there.

The landing claims to be 1.0-branch-only but for whatever reason still lives on
the trunk. IMHO this wallpaper should be removed and a proper fix (for bug
59686) should be done.
adt: nsbeta1-
Keywords: nsbeta1nsbeta1-
There has been a lot of work in the Page Info code recently.  CC'ing Daniel to
see if this one is safe to mark fixed or worksforme.
This bug is now WFM on Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a5)
Gecko/20041117 MultiZilla/

Should it be marked as such (as recommended in bug 195492#c67 )?
Isn't the wallpaper code still there to catch this? I.e. the bug is still there
but it has been worked around in the pageinfo code?
sicking: that's correct.

Raj Bhaskar, please read the entire bug carefully before commenting....
Blocks: 353557
No longer blocks: 353557
Component: DOM: Core → DOM: Core & HTML
QA Contact: stummala → general
Is there a point to leaving this bug open? There was a crash, it was wallpapered, and there's another bug on fixing it the right way (comment 41). As long as bug 59686 exists why do we need this one too? (also the testcases linked from here are gone reducing the usefulness further).
Keywords: testcase-wanted
Whiteboard: [needs answer to comment 47 or should be closed][needs testcase]
I'm going to mark this fixed per comment 47 and the wall paper landing.
Closed: 17 years ago10 years ago
Resolution: --- → FIXED
Crash Signature: [@ js_GetProperty]
You need to log in before you can comment on or make changes to this bug.