Closed Bug 111944 Opened 24 years ago Closed 23 years ago

JRE 1.3.1 (01a upwards) hangs with fphover.class

Categories

(Core Graveyard :: Java: OJI, defect)

Product:
Core Graveyard
Component:
Java: OJI
Platform:
x86
Windows 2000
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX

People

(Reporter: iannbugzilla, Assigned: joshua.xia)

References

Details

(Keywords: hang, Whiteboard: fphover)

Attachments

(2 files)

Frontpage's fphover class file
9.11 KB, application/octet-stream
Details
gettingRidOfJRE1.304.png
38.49 KB, image/png
Details
From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.6+) Gecko/20011125 BuildID: 2001112508 Have some intranet pages designed using frontpage's fphover.class which work fine (well 90% of the time) with JRE 1.3.1 but when used with JRE 1.3.1_01 causes mozilla to hang Reproducible: Always Steps to Reproduce: 1. Design a page which includes use of fphover.class 2. Install mozilla and JRE 1.3.1_01 3. Try loading page Actual Results: Mozilla hangs but can be closed by clicking on the close window button Expected Results: Page loads as it does most of the time with JRE 1.3.1 <html> <head> <title>Content</title> <meta name="GENERATOR" content="Microsoft FrontPage 4.0"> <base target="main"> <meta name="Microsoft Theme" content="none"> <meta name="Microsoft Border" content="none"> </head> <body topmargin="2" leftmargin="5"> <p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <font color="#800000" face="Arial" size="4"><u><b>Topics</b></u></font></p> <table border="0" width="128" cellspacing="1"> <tr> <td width="122"> <applet code="fphover.class" codebase="../" width="120" height="20"> <param name="font" value="Helvetica"> <param name="fontstyle" value="bold"> <param name="effect" value="fill"> <param name="color" value="#66CCFF"> <param name="bgcolor" value="#000000"> <param name="fontsize" value="11"> <param name="hovercolor" value="#FF9933"> <param name="target" value="_self"> <param name="textcolor" value="#000000"> <param name="text" value="Best Value"> <param name="url" valuetype="ref" value="../best_value/best_value_front_content.htm"> </applet> </td> </tr> </table> </body> </html>
For testing purposes
Bug 57372 contains many fphover comments. Doesn't looks like dup, but may be helpful
I've just tried the URL http://www.house.gov/jacksonlee and it hangs in the same way with JRE 1.3.1_01 on Windows 2000 *** This bug has been marked as a duplicate of 57372 ***
Status: UNCONFIRMED → RESOLVED
Closed: 24 years ago
Resolution: --- → DUPLICATE
I've been advised this may not be related to bug 57372 after all and I've tested the pages and the URL http://www.house.gov/jacksonlee with appletviewer from JDK 1.3.1 and 1.3.1_01 and everything works fine with that. So a hang occurs only when using JRE 1.3.1_01 through mozilla and not with the JDK of the same version.
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
Build ID: 2001 11 23 03. Windows 2000. WFM, i.e. no crash when loading <http://www.house.gov/jacksonlee/ > or playing with it. Directory of E:\local\mozilla-win32-talkback\bin\plugins\np*.dll 2001-08-08 15:11 49 245 NPJava11.dll 2001-08-08 15:11 53 341 NPJava12.dll 2001-08-08 15:11 49 245 NPJava32.dll 2001-08-08 15:11 53 338 NPJava131_01.dll 2001-11-23 9:42 17 792 npnul32.dll 2001-08-08 15:11 45 150 NPOJI600.dll I use the English version of JRE, not the international one.
WFM w/ JRE 1.4.0 Beta3 WinMe 2001112603
The files from standard edition (not international version) of JRE 1.3.1 are dated 6th May 2001 with java -version giving a build of 1.3.1-b24. The files from standard edition of JRE 1.3.1_01 are dated 5th October 2001 with java -version giving a build of 1.3.1_01a.
JRE 1.3.1 06/05/01 11:14 49,245 NPJava11.dll 06/05/01 11:14 49,245 NPJava12.dll 06/05/01 11:14 53,338 NPJava131.dll 06/05/01 11:14 49,245 NPJava32.dll 06/05/01 11:14 45,150 NPOJI600.dll JRE 1.3.1_01 05/10/01 13:53 49,248 NPJava11.dll 05/10/01 13:53 53,344 NPJava12.dll 05/10/01 13:53 53,341 NPJava131_01.dll 05/10/01 13:53 49,248 NPJava32.dll 05/10/01 13:53 45,153 NPOJI600.dll
Okay I was using the international version of JRE 1.3.1_01 (or JRE 1.3.1_01a as it's called), surely this should work with Mozilla?
Just tested with the international version of JRE 1.4.0 beta 3 and that works fine too. JRE 1.3.1_01a (international version) also crashes Netscape 6.2
Ian: sometimes you refer to hang (that could be due to race conditions and deadlock) and sometimes you refer to crash. Could you please clarify that actually happens? Also, would you please try to open java console in advance, set trace level to 5 and see what is reported there.
It always hangs not crashes. Okay I fired up Mozilla with JRE 1.3.1_01a (International) Started up the console and selected the trace level to 5 Clicked onto http://www.house.gov/jacksonlee Both mozilla and the java console appear to be hung You can sometimes minimise and bring back each of the windows but the windows are blank. Clicking on close on mozilla will shutdown mozilla and the java console. If you look at the task manager, mozilla doesn't appear as an application but as a process using up the whole of one CPU.
WFM. Windows 98. Mozilla 0.9.6 Build ID 2001112703. JRE 1.3.1_01, English version. http://www.house.gov/jacksonlee/ Please check your other plugin directories -- Netscape 6.x and Netscape 4.x -- if you have them. Mozilla reads plugins from those directories. If you have Java plugin files there, they might be conflicting with JRE 1.3.1_01.
I don't have Netscape 6.x installed on the same box that I have mozilla installed on and Netscape 4.x does not have any java plugins installed. Also you are running the non-international version of JRE 1.3.1_01 (files dated 8th August 2001) whereas I am running the international version of JRE 1.3.1_01 (files dated 5th October 2001). Can someone else test the international version of JRE 1.3.1_01 against mozilla?
I have tried the current mozilla trunk with the international JRE 1.3.1_01a. The URL http://www.house.gov/jacksonlee hangs both browser and the java console.
Seeing this is now confirmed can someone change the status to confirmed?
Status: UNCONFIRMED → NEW
Ever confirmed: true
It seems at the leaset the problem has been fixed in JRE1.3.1 and later (JRE1.4), right?
It's okay in the latest 1.4 beta international version but not in the latest production 1.3 international version (1.3.1_01a)
Works for me with jre1.3.1_01, jre 1.4beta3. jre1.3.1_01a hangs the browser. I'm running mozilla 0.9.6 on Win NT4.0
Just tested BuildID 2001122003 with the latest release of 1.3.1 (which is 1.3.1_02) and the hang happens on both the US version and the International version.
Altered summary to better reflect extent of problem
Summary: JRE 1.3.1_01 crashes with fphover.class → JRE 1.3.1 (01a upwards) hangs with fphover.class
*** Bug 126176 has been marked as a duplicate of this bug. ***
Now that sun have released a non-beta version of 1.4. Should something be put in the release notes about using versions of JRE 1.3.1 01a and above with sites that use fphover.class and recommend to use either a verison of JRE 1.3.1 prior to 01a or JRE 1.4?
Keywords: hang
Confirmed this bug with Win 2000, Mozilla 0.9.6 - 1.0 RC 3, and JDK 1.3.1_02 (w/ JRE 1.3.1_02). Will also hang Netscape 6.X . Fixed by installing JDK 1.4 (JRE 1.4) and keeping Mozilla 1.0 RC3 and Netscape 6.2.3 installed.
Dupe of bug 57372?
As stated in bug 57372 this can only be marked as a dupe if bug 57372 is changed from just being Linux to being All
*** This bug has been marked as a duplicate of 57372 ***
Status: NEW → RESOLVED
Closed: 24 years ago → 23 years ago
Resolution: --- → DUPLICATE
This is not dupe of 57372! Reopening. Please see comment #92 in description of bug 57372 for required symptoms! It does not crash here at all, moreover it does not even hang with appletviewer and only hang with mozilla => this is some kind of deadlock. There are several other bugs on porblems releated to running multiple applets or instances of the same applet on the same page.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
It definitely hangs both mozilla and the java console but if you upgrade to JRE 1.4 everything works fine (but loads slowly).
Status: REOPENED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → WORKSFORME
*** Bug 166406 has been marked as a duplicate of this bug. ***
*** Bug 166060 has been marked as a duplicate of this bug. ***
*** Bug 165771 has been marked as a duplicate of this bug. ***
*** Bug 162654 has been marked as a duplicate of this bug. ***
*** Bug 153424 has been marked as a duplicate of this bug. ***
*** Bug 153327 has been marked as a duplicate of this bug. ***
*** Bug 152567 has been marked as a duplicate of this bug. ***
*** Bug 152198 has been marked as a duplicate of this bug. ***
*** Bug 151790 has been marked as a duplicate of this bug. ***
*** Bug 150441 has been marked as a duplicate of this bug. ***
*** Bug 147828 has been marked as a duplicate of this bug. ***
Depends on: fphover
*** Bug 171536 has been marked as a duplicate of this bug. ***
QA Contact: pmac → petersen
*** Bug 173559 has been marked as a duplicate of this bug. ***
*** Bug 176280 has been marked as a duplicate of this bug. ***
why is this bug's status "RESOLVED"? one should not have to upgrade their JRE to keep their browser from hanging, should they? the browser should be bullet-proof. a poorly written plugin shouldn't cause me to have to force-kill mozilla. i've lost all my state a few times due to this bug :(
joe? can we please change the status to REOPENED? it turns out that JRE 1.4.1_01 causes bluescreens with certain video drivers so upgrading is not a viable workaround for many people. i am now getting bluescreens on my thinkpad running XP which is worse than the original problem of mozilla hanging :( see http://java.sun.com/j2se/1.4.1/relnotes.html#2d for info on the crashes that 1.4.1 causes.
Marc: try to configure your Java Plugin by disabling java2d advanced features as suggested in jdk release notes (You can do this using ControlPanel tool - usually accesible as "Java Plugin" in Contol Panel on Win platform) The browser crash after plugin crash is NOT possible to fix in current java plugin support model. There are several other open bugs related to redesign of this and hopefully it will happen later (this require changes on jre side too). If you really want to stay with 1.3 then you can try to push Sun's developers to backport fix for this annoying problem (i mean fphover.class).
hey, igor. thanks for the informative comments! i had already disabled the use of direct3d for java2d in the case of direct launching of .jar files in XP. i did this by changing the command line parameters of the "open" action via Windows Explorer -> Tools -> Folder Options -> File Types -> Extensions -> JAR -> Advanced -> Actions: open -> Edit -> Application used to perform action: "C:\Program Files\Java\j2re1.4.1_01\bin\javaw.exe" -Dsun.java2d.d3d=false -jar "%1" %* thanks to your pointer about the Java Plug-in control panel, i tried to make the same change for the plugin. unfortunately, the control panel, itself, is written in java and when i clicked the apply button, the bug was tickled and i bluescreened in my ATI driver :( in any case, i did not realize that the browser hang was not possible to fix in the current java plugin support model. you mention several other open bugs related to the redesign of the model, but you didn't mention them by number :( do you know what they are? if this bug is meant to track the bug in java, not the the bug in the browser's java plugin support, then i agree that this bug should remain resolved. but in that case, can we reopen bug 176280 or use some other bug to track the browser hang bug? if, on the other hand, this bug is meant to track the browser hang, it should remain open regardless of the fact that there are other bugs to track the redesign of the java plugin support model. this is why bugzilla supports the concept of bug dependencies :) agree? re: asking sun to backport the fix to JRE 1.3, i'm not a big java user and don't care enough to expend the effort. though i agree that bug fixes should be backported to all support release chains, i don't want to get involved ;) as for sun's use of functions that are apparently commonly misimplemented by driver writers, once again, that's up to sun to resolve how they want to handle the problem. in sun's defense, they should not be overly concerned with other people's bugs. if they are using an exposed function that causes a driver to panic the machine, the driver absolutely has to be fixed regardless of what sun chooses to do. user-level applications should not be able to bring a machine to its knees... even malicious ones. to this end, i have already escalated a case with IBM to get a fixed video driver released for my laptop (thinkpad X20 running XP). so far, it is only at the Service Request stage and is being tracked as SR 1-136720946. thanks again for caring! marc
*** Bug 177804 has been marked as a duplicate of this bug. ***
ping
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
*** Bug 179987 has been marked as a duplicate of this bug. ***
*** Bug 179978 has been marked as a duplicate of this bug. ***
*** Bug 181246 has been marked as a duplicate of this bug. ***
reassign to me
Assignee: joe.chou → joshua.xia
Status: REOPENED → NEW
*** Bug 185999 has been marked as a duplicate of this bug. ***
dup of 132931 *** This bug has been marked as a duplicate of 132931 ***
Status: NEW → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → DUPLICATE
Whiteboard: fphover
It should be marked the other way round.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
*** Bug 132931 has been marked as a duplicate of this bug. ***
*** Bug 117749 has been marked as a duplicate of this bug. ***
ian@arlen.demon.co.uk, We have no way to fix this bug because JRE1.3.1 will not accept any bug fix now. Shall we close this one? Or this will be opened forever :-)
no more bugfixes for jre 1.3.1? who made that call? silly, imnsho. anyway, if that is really the case, then i guess this should be CLOSED - WONTFIX :( anybody know the bug numbers relating to the rework of java to keep mozilla from crashing when the JRE jumps the shark? marc
I've a feeling it was left open to try and catch more dupes but I'm "happy" to have it closed as won't fix
Sorry, I'm closing.
Status: REOPENED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → WONTFIX
ok. since this bug seems to be tracking the actual bug in java, not the issue of mozilla hanging when java hangs, i'm going to re-open bug 176280 (like i originally suggested in comment #47) to track the hanging of mozilla. marc
Blocks: 176280
*** Bug 190622 has been marked as a duplicate of this bug. ***
*** Bug 190719 has been marked as a duplicate of this bug. ***
*** Bug 176280 has been marked as a duplicate of this bug. ***
*** Bug 196548 has been marked as a duplicate of this bug. ***
*** Bug 211579 has been marked as a duplicate of this bug. ***
*** Bug 187462 has been marked as a duplicate of this bug. ***
*** Bug 228013 has been marked as a duplicate of this bug. ***
- I have long moved to 1.4.*, but I still get this error - manually, I removed all NPJava13*.dll's on my system. - as per comment #47, my config looks fine. - but in my Control panel and my add/remove programs, I still have some traces left of 1.3.1_04 and the system refuses to remove as per the attached screen-shot ==> any hints how to purge my system from that would be highly appreciated
As to the added duplicate Bug 228013, I have to WFM it in retaliaton for all the WFMs I've gotten on bugs as used on my system. That page works fine for me with: Win98SE Java 1.4.2_02 Moz 1.5
re: comment 71, this isn't the forum for sun tech support. open an issue with them or take the discussion to an appropriate mailing list or newsgroup re: comment 72, the comment should have gone on bug 228013. how does saying WFM on this bug help the discussion of this bug that has been RESOLVED / WONTFIX for almost a year? bah, humbug
Scrooge: Re Comment 72: I thought the strikeout of a bug, when it is declared to be a duplicate of another bug, meant that its file was closed; and that if one bug is a duplicate of another, future comments on the former would be considered relevant to the latter. If not, why strike a bug out when declaring it a duplicate of another bug? Ray
you thought wrong :P the strikout rendering is just so that you can easily tell the bug has been resolved. but this doesn't mean locked. you can still add comments to it (as we're now proving). peace, marc
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: