Closed Bug 187103 Opened 22 years ago Closed 11 years ago

DHTML takes over control of browser

Categories

(Core :: Layout, defect)

PowerPC
macOS
defect
Not set
critical

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: dhtmlkitchen, Unassigned)

References

()

Details

(Keywords: hang, perf)

Attachments

(3 files)

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...
Keywords: qawanted
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.
Keywords: perf
*** 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
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
Product: Browser → Seamonkey
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
No Problems
There has been some awesome progress on this browser!


One thing that is still a problem is that in Mac, alerts get put into the window
menu.

If you run this and then move your mouse around, there will be a huge stack of
[Javascript Application] in the window menu:

javascript:void(onmousemove =  function(e) { alert(e && e.pageX);  });

Could this be prevented so that I get 1 alert box at a time?
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
Assignee: asa → nobody
QA Contact: asa → layout
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
Closed: 11 years ago
Keywords: qawanted
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: