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).
It sounds like you hit bug 309706.
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
Flash (8) is installed, no ad-blocking.
I hang with SeaMonkey branch/trunk builds and Java 1.4.2_08. After closing SM it remains as zombie process in memory.
13 years ago
Depends on: 309706
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=
Is this still a problem, now that bug 309706 is fixed?
(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
Fixed by the check-in for bug 309706.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → FIXED
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?
(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.