Closed
Bug 313212
Opened 19 years ago
Closed 19 years ago
quote.com - SeaMonkey crashes when above page is loading (page includes a Java applet), TalkBack did not launch
Categories
(SeaMonkey :: General, defect)
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: epp, Unassigned)
References
()
Details
(Keywords: crash)
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20051020 SeaMonkey/1.1a
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20051020 SeaMonkey/1.1a
In URL above, the symbol T on the end can be any valid stock ticker symbol.
When the above page (which includes a Java applet) loads in SeaMonkey, the
browser crashes, but TalkBack DID NOT launch afterwards.
Was able to get SM to crash three successive times using different ticker
symbols, and each time, TalkBack did not launch after the crash. "Complete" was
selected at installation.
The same page does not crash Firefox 1.0.7.
Reproducible: Always
Steps to Reproduce:
1.Load in above URL
2.SeaMonkey attempts to load page
3.SeaMonkey crashes and does not launch TalkBack.
Actual Results:
SeaMonkey crashes, does not launch TalkBack.
Expected Results:
1. TalkBack should have launched after each crash.
Or
2. SeaMonkey should have displayed the page without crashing.
Java version (according to Java Control Panel) is 1.5.0 (build 1.5.0_04-b05).
Comment 1•19 years ago
|
||
It sounds like you hit bug 309706.
Comment 2•19 years ago
|
||
wfm Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.9a1) Gecko/20051012 SeaMonkey/1.1a
Java Plug-in 1.5.0_05
looked at T, AMD, INTC, changed to view Q,W,D didn't crash. I don't have Flash
installed, or ad-blocking extensions. I'm adblocking with a hosts file.
Could only lokk for some minutes, until the demo timed out. Closing the tab and
returning to the page later didn't help, guess I've got to clear the related
data in the Java cache, something like LCwatermark.gif-32bithex-32bithex.gif.
Version: unspecified → Trunk
I hang with SeaMonkey branch/trunk builds and Java 1.4.2_08. After closing SM it remains as zombie process in memory.
Comment 5•19 years ago
|
||
crashed using MozillaTrunk Build ID 2005102717
TB11167392X, TB11167383W identical to Incident ID: 11208851 filed for Bug 309706
crashed using same build/setup as in the WFM comment #2:
MozillaTrunk Build ID 2005101205
TB11210070W Talkback with symbols, identical to TB10755711Y filed for Bug 311933
Stack Trace:
JPINSCP.DLL + 0xaa87 (0x6d42aa87)
repeating till end of record:
PluginWndProc [c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/modules/plugin/base/src/nsPluginNativeWindowWin.cpp, line 344]
JPINSCP.DLL + 0x3a20 (0x6d423a20)
search on PluginWndProc:
https://bugzilla.mozilla.org/buglist.cgi?query_format=&long_desc_type=substring&long_desc=PluginWndProc&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&emailassigned_to1=1&emailtype1=exact&email1=&emailassigned_to2=1&emailreporter2=1&emailqa_contact2=1&emailtype2=exact&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0=
Comment 6•19 years ago
|
||
Is this still a problem, now that bug 309706 is fixed?
Comment 7•19 years ago
|
||
(In reply to comment #6)
> Is this still a problem, now that bug 309706 is fixed?
Seems wfm, but not very much tested.
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.9a1) Gecko/20051031 SeaMonkey/1.1a
Tinderbox BuildID 2005103121
I checked it once this morning until the demo timed out. Wanted to recheck now, but have to clear the java chache, I guess. No crash at first test, all was working. No crash at second test session, but a java exception, may be related to the cached timed-out demo.
I didn't test yesterdays nightly BuildID 2005103110 on this bug, it was crashing on another one that was working ok with the tinderbox build.
wfm
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20051102 Firefox/1.6a1 ID:2005110205
Comment 9•19 years ago
|
||
Fixed by the check-in for bug 309706.
Status: UNCONFIRMED → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Reporter | ||
Comment 10•19 years ago
|
||
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20051102 SeaMonkey/1.1a
When I tried accessing the same page, Sea Monkey displayed a window indicating an unresponsive script. After selecting "Continue", the rest of the page loaded and the chart appeared.
Is this "unresponsive script" window, something that is to be expected all the time?
Comment 11•19 years ago
|
||
(In reply to comment #10)
> Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1)
> Gecko/20051102 SeaMonkey/1.1a
>
> When I tried accessing the same page, Sea Monkey displayed a window indicating
> an unresponsive script. After selecting "Continue", the rest of the page
> loaded and the chart appeared.
>
> Is this "unresponsive script" window, something that is to be expected all the
> time?
The "unresponsive script" warning comes, if the script is unusally slow. That can be a slow computer, or a fast computer with a script wanting a faster computer. I'm seeing that warning sometimes on my Celeron 333. Mostly I can ignore it, sometimes the computer is hanging after I ignored it. I rarely see it at a faster Athlon XP1600, but often hang there if I ignore it.
This warning is a rough guess of Seamonkey to give you a chance to stop a script before it freezes your computer, it's up to you to decide it's worth a try, or you already know the result if this URL will work or freeze.
You need to log in
before you can comment on or make changes to this bug.
Description
•