128666 - Mozilla should still display page output during long loops

Status: RESOLVED DUPLICATE of bug 30942

(Core :: DOM: Core & HTML, defect)

Description

[Brian 'netdragon' Bober]

Mozilla doesn't update the webpage during tight loops. Not a dupe of bug 13350
or bug 30942. This has to do with display, not responsiveness and isn't
necessarily infinite loops. Will attach testcase.

Comment 1

[Brian 'netdragon' Bober]

Attachment: Testcase - notice the first time it doesn't display anything

Something needs to yield occasionally to allow other parts of mozilla to work.

Comment 2

[Alfonso Martinez]

I think that the current behaviour is the correct one.
Your testcase is very simple, but what would happen with a very complex loop? If
you want to move a lot of elements, with your proposal after any change to any
element the display will be refreshed, meaning that a lot of CPU would be spent
for this task.
If the author of the web page wants the process to refresh the display, it can
be done like in your phase 2, using a timeout.

Comment 3

[Phil Schwartau]

Over to DOM Level 0 for a decision -

FWIW, as far as I can see Mozilla and IE6 are behave identically
on Brian's testcase. Brian, is that your experience, too?

Comment 4

[Brian 'netdragon' Bober]

Alfonso: I definately agree that it shouldn't be displayed every iteration, but
maybe every second or so.

Comment 5

[Brian 'netdragon' Bober]

Attachment: Longer testcase

You can see in this testcase that a user might think the page isn't displaying
anything. This would last for about 10 seconds and by then the user might give
up. This might also be a problem on the chrome (I'm not sure), where js might
stop the display. 

IE does a lot of things wrong, and we shouldn't try to emulate them.

The browser should refresh the display every .5 seconds or so regardless of
long loops.

See also bug 30942 about Mozilla staying responsive during endless loops.

Comment 6

[Boris Zbarsky [:bzbarsky]]

This is a dup of bug 30942, since the same layout engine handles the UI and the
page.... Solving the problem described in this bug is completely equivalent to
solving the problem described in bug 30942.

*** This bug has been marked as a duplicate of 30942 ***