3.41 KB, text/html
3.10 KB, text/html
404 bytes, text/html
Build ID: 20021130 / mac os x Bug 21762, comment 92 http://www.24fun.com/downloadcenter/benchjs/benchjs.html is now worse in the latest release of mozilla. I have to force quit mozilla. The problem is that mozilla does not yeild to ui events, so I can't even close the window. I have to switch to a different application and then force-quit. Loading http://24fun/ causes the browser to perform unacceptably slow. For instance, text is entered into the textarea (in another tab-pane) at about 1 letter per second. I type a sentence and watch and wait for the letters to slowly appear.
a minimal testcase would be nice...
Created attachment 110328 [details] Shows a progressbar that is not displayed until the very end Mozilla does not react to any type of events, including clicking items in the screent menubar, moving, resizing the window. The progress bar is displayed after 1:50 (one minute, fifty seconds). There is no gradual increase of the progress bar, rather it is displayed all at once in its full lenght. After that "all done" pops up.
*** Bug 184352 has been marked as a duplicate of this bug. ***
worksforme moz 2003040308/win98 Mac-only bug? Reporter (Garrett Smith), can you still reproduce the bug? (setting severity to critical because of 'hang')
Severity: normal → critical
Created attachment 119610 [details] Exponential string concatenation causes hang/req restart The example works now, and I was surprised when I went to http://3dhtml.netzministerium.de/ and successfully demoed the examples. The problem is not DHTML performance, though. The problem is that Mozilla does not yeild to UI events when a script is executing. Here is the script for the attachment: var s = "Hello "; for(var i = 0; i < 10000; i++) s += s; document.write(s); This example exponentially increases the value of s; 0 s = "Hello " 1 s = "Hello Hello" 2 s = "Hello Hello Hello Hello" 3 s = "Hello Hello Hello Hello Hello Hello Hello Hello" String s soon becomes very large and grown to a monstrous length (you do the math), and the concatenation takes a lot of time. My test: 1) drag file to window in mozilla. 2) try to close the window, if successful, then I am done. Result: Mozilla passed 3) otherwise, if window will not close, switch to finder and try to force quit, if successful, then I am done. Result: Mozilla failed. 4) otherwise, if I cannot force-quit, then push the reset button. Result: Mozilla Failed. My result: I made it to step 4. Result: Mozilla failed. Expected Result: Mozilla should allow me to close the window. This can be accomplished if Mozilla will periodically yeild while processing scripts. To be fair, this test is contrived and wouldn't exist in any reasonable script. Perhaps as DHTML handling becomes better, we will see fewer hangs, thus making a solution to this bug unnecessary. But since better DHTML handling does not cover every possible case that could cause a hang such as this, I think that this should be fixed.
cc'ing a few people who can give input
Here is a real world (not contrived) case where I can't close the window: http://interact.pregnancytoday.com/guest/07993arc.htm The machine doesn't need to be rebooted because I am able to switch to finder and force-quit.
http://interact.pregnancytoday.com/guest/07993arc.htm works for me. The benchjs page does not hang the browser, but neither does it work quite right. Test 1 takes a long time, and never displays a red progress bar. but it does not hang. The examples at http://3dhtml.netzministerium.de/ do not work for me, they do not display properly. Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5) Gecko/20030916 PPC G3 320MB ram I tested the benchjs on 2 other machines, all finished the 5 tests with similiar results, except for test 1: PII 350 128MB W2K Mozilla 1.5rc1 : 3 seconds display red bar: OK PIII 500 256MB Linux Mozilla 1.4 : 3 seconds display red bar: OK G3 500 320MB OS X Mozilla 1.5rc1: 67 seconds display red bar: NO
the three attached testcases loaded ok for me with linux trunk 2005032405 The red progress bar at the URL and the first two attachments worked fine (displayed during the test) Mozilla was not so happy about the third test, but that's because it used 840MB of RAM (I have 512MB). It loaded it fine. I loaded it again, but tried to kill it while it was loading and that worked fine. Practically speaking, if you can't kill Mozilla, it's your OS's fault. Anyway, Garret: do you still see the original problem you reported with a recent build?
Component: General → Layout
Product: Mozilla Application Suite → Core
I had no problems with the browser while it loaded 24 fun. But I had the freezeing problem doing the 3d solar system at the 24fun.com website on WinXP. LAst night I had no problems, I am using 1.8b2 and now I am having trouble. FF and IE both work fine on that site.
Is this still an issue, this seems to be wfm on win32
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:25.0) Gecko/20130731 Firefox/25.0 Works for me also on the latest Nightly and Mac OS X 10.8. Setting the status of this bug to Resolved Worksforme. If anyone else is still able to reproduce or has more information about how to reproduce this issue, please reopen.
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.