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 - firstname.lastname@example.org: would it be possible for you to download a Talkback-enabled build? (see http://www.mozilla.org/releases/) 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
QA Contact: pschwartau → imajes-qa
Created attachment 89477 [details] backtrace a 12 h. old CVS, Linux (non-debug, with symbols) seems to crash here: #0 0x4009b92c in js_GetProperty () from /libmozjs.so #1 0x4008eea2 in js_Interpret () from libmozjs.so #2 0x40087f77 in js_Invoke () from libmozjs.so #3 0x40595595 in nsXPCWrappedJSClass::CallMethod () from libxpconnect.so #4 0x40591413 in nsXPCWrappedJS::CallMethod () from libxpconnect.so #5 0x4018444e in PrepareAndDispatch () from libxpcom.so #6 0x401844b2 in nsXPTCStubBase::Stub3 () from libxpcom.so #7 0x40ed5e47 in nsTreeWalker::TestNode () from libgkcontent.so #8 0x40ed5c8e in nsTreeWalker::ChildOf () from libgkcontent.so #9 0x40ed54b2 in nsTreeWalker::FirstChildOf () from libgkcontent.so #10 0x40ed5d31 in nsTreeWalker::ChildOf () from libgkcontent.so #11 0x40ed54b2 in nsTreeWalker::FirstChildOf () from libgkcontent.so
with an official trunk linux 20020617xx i see the same as in comment 2 In addition, the "links" tab is blank
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
Status: UNCONFIRMED → NEW
Ever confirmed: true
Crashed for me, although it thought about it for a while. Win98SE build 2002062704-TRUNK. 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 finished. 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 www.heise.de.
email@example.com: 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: http://www.meinebaustelle.de/applet/parameter.html 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.
js_GetProperty is a topcrash on the trunk. Added topcrash to keywords and modified summary for tracking.
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 applet. adding NEW URL from the Reporter.
I think this crash is caused by an incorrect value being sent for JSProperty*. http://lxr.mozilla.org/seamonkey/source/js/src/liveconnect/jsj_JavaObject.c#804 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...
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. ***
Created attachment 92302 [details] [diff] [review] workaround 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] workaround 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] workaround r=bzbarsky
Attachment #92302 - Flags: review+
->sicking to checkin
Assignee: jst → sicking
Comment on attachment 92302 [details] [diff] [review] workaround obsoleting, this one didn't make it to the branch
dupping this to it's real problem *** This bug has been marked as a duplicate of 59686 ***
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → DUPLICATE
Comment on attachment 92302 [details] [diff] [review] workaround trying for branch again...
Attachment #92302 - Attachment is obsolete: false
17 years ago
Keywords: adt1.0.1, mozilla1.0.1, nsbeta1
Marking adt1.0.1-. Since this is branch only it'll be fixed in the next release.
Keywords: adt1.0.1 → adt1.0.1-
Comment on attachment 92302 [details] [diff] [review] workaround oki
*** 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).
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Looks like there was a midair collision that removed the dependancy.....fixing.
Created attachment 103048 [details] MacsBug stdlog from testcase in comment #13 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 http://www.meinebaustelle.de/applet/parameter.html 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: topcrash → topcrash-
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. http://lxr.mozilla.org/mozilla/source/xpfe/browser/resources/content/pageInfo.js#568 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.
Keywords: nsbeta1 → nsbeta1-
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/22.214.171.124c 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....
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).
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.
Status: REOPENED → RESOLVED
Last Resolved: 17 years ago → 10 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.