Closed Bug 14666 Opened 25 years ago Closed 24 years ago

Running this JavaToJavaScript test causes apprunner to crash.

Categories

(Core Graveyard :: Java: OJI, defect, P3)

x86
Windows NT
defect

Tracking

(Not tracked)

VERIFIED WORKSFORME

People

(Reporter: leilag, Assigned: xiaobin.lu)

References

Details

(Keywords: crash, Whiteboard: [nocrash])

Attachments

(2 files)

To reproduce, - Bring up LiveConnect/html/sjavatoscript.html This will pop up an alert stating that the test runs successfully. However, notice at the same time that it pops up the application error dialog. I tried not to pop up alert, but I still could see the same problem.
Attached file tar file of LiveConnect test. (deleted) —
Can someone please code review this 10/20/99 patch? Ed
Looked at the fix, have one question: I never did trust the evaluation of arguments in an "if" expression because I've never known well enough how compilers behave. So, whenever I see something like if (x && test(x)) I get nervous, and tend to unroll the test: if (FALSE == x) then // get outtahere now, before trying to continue if (test(x)) then // whatever; if you've made it here, x is non-NULL So, that's my only comment about the fix. I don't know anything about what the fix does, except that it *looks* like it's checking to see if there's a context before trying to check for exceptions in that context. I'm assuming that there's no context at this point because either there's no JVM or this code is being hit before the JVM is fully initialized? If you can tell me the "if (cx&&JS_IsExceptionPending(cx))" will evaluate correctly, then I'm okay with the bug fix. Still, it would be good to have a JavaScript dude look at what's going on here.
It is indeed a reasonable expectation that the sub-expressions of a condition like: if( a && b && c ) will be evaluated from left to right only until one of them evaluates to false (or 0, or NULL). Not only is this defined by the C standard, but it is the way that any C/C++ compiler I have ever used has behaved.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Okay, Jeff, I buy your reasoning. The patch is checked in. I'm claiming this bug is now fixed.
Verified in the 2000030914-M15 build using the supplied test case.
Status: RESOLVED → VERIFIED
Tried this on Win98/NT with 09/22 build of mozilla (around PR3 branch time) with PR3 JRE bits. Does not work. It does not invoke an alert box (no exceptions on javaCOnsole).
Reopening this bug. It does not crash, but it does not display an alert box. (Does on Ie and Netscape 4.75) Tried with FCs bits of JRE on Winnt/98
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
This is a regression caused by [Bug 53849] Java -> JavaScript calls blocked by security checks. This bug will be fixed when that gets approved by the PDT and checked in. Marking - depends on 53869.
Depends on: 53849
*** Bug 54765 has been marked as a duplicate of this bug. ***
Keywords: crash
Marking [nocrash] based on rpallath@eng.sun.com 2000-10-24 11:02.
Whiteboard: [nocrash]
Re-assigning to module owner. I bet this works now and can be closed; perhaps Xiaobin can verify?
Assignee: drapeau → edburns
Status: REOPENED → NEW
Updating the QA contact
QA Contact: paw → shrir
Xiaobin, can you please try this?
Assignee: edburns → xiaobin.lu
Status: NEW → ASSIGNED
It works for me! But notice, if you try it, you need to apply the Patrick's patch for bug 63466(Liveconnect registration was removed)to make this work. Raju: Please try it and let me know if you have any problems. Thanks!
Mark this bug as WORKSFORME.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago24 years ago
Resolution: --- → WORKSFORME
Verfied on my NT box using nighlty build of mozilla. Fixed...
Status: RESOLVED → VERIFIED
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: