325384 - 100% CPU load after resume if page viewed contains blinking text, flash image

Status: RESOLVED DUPLICATE of bug 265172

(Core :: DOM: UI Events & Focus Handling, defect)

Description

[Xuân Baldauf]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051219 SeaMonkey/1.0b
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051219 SeaMonkey/1.0b

When implementing repetetive actions required to display an HTML page, especially when implementing blinking text (for the "<blink/>" tag), SeaMonkey (or Gecko?) seems to execute every single step of every single loop which was scheduled for past time.

More precisely, when SeaMonkey is to display blinking text, there is a "text on" event and an "text off" event, and these events repeat again every seconds. When, however, the computer running SeaMonkey is set into standby (suspend to ram), the clock advances without SeaMonkey being able to react appropriately (invoke another "text on" and another "text off" event for every second). When the computer is then resume from standy, SeaMonkey tries to catch up, executing every "text on" and "text off" event which should have been executed long in the past.

This not only leads to senseless very fast blinking, moreover, this also leads to much longer resume delays and avoidable CPU time and energy consuption, which especially is a nuisance when the computer is battery powered (i.e. a laptop).

Thus, SeaMonkey should not try to catch up the clock advancements if the clock advances so far (i.e. due to suspend and resume) that the clock advancement covers multiple loops and these loops have no side effects. (They do not have a side effect if a "text off" action is completely overridden by subsequent "text on" actions. They have a side effect, for example, if at each loop cycle execution a counter is increased.)

Not only the blinking code, but every code involving repetitive, side-effect less actions should be reviewed and changed to skip whole loop cycles in case of substantial, whole-loop-cycles-spanning clock advancements (as caused by standby and resume actions).



Reproducible: Always

Steps to Reproduce:
1. View an HTML page which contains blinking text, like ( http://www.faqs.org/docs/htmltut/_BLINK.html )
2. Set your computer into standby modus. 
3. Wait some hours
4. Resume from standby modus
5. Watch the HTML page which contains blinking text.

Actual Results:  
The text blinks very fast and SeaMonkey needs 100% of the available CPU time.

Expected Results:  
The text should blink as normal.

Comment 1

[Masatoshi Kimura [:emk]]

Still reproducable with Seamonkey-trunk?
ftp://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/latest-trunk/

Comment 2

[HyperHacker]

Attachment: Simple test case

Comment 3

[HyperHacker]

Sorry, forgot to include my comment.
Confirmed on Firefox 1.5.0.2 using Standby in Windows XP SP2. Entering standby for about 7 hours 30 minutes results in 9 minutes 27 seconds of delay and rapid blinking. The thread using most of the CPU power (92-94%; interestingly, rarely above 94%) is in firefox.exe!jpeg_fdct_islow+0x247ac, and is running even though there are no images on the page.
Probably the same issue as bug 265172.

Comment 4

[Wayne Mery (:wsmwk)]

(In reply to comment #3)
> Probably the same issue as bug 265172.

Do you still see this problem on trunk build http://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/latest-trunk/  given that bug 265172 was fixed in June? 

Comment 5

[HyperHacker]

(In reply to comment #4)
> (In reply to comment #3)
> > Probably the same issue as bug 265172.
> 
> Do you still see this problem on trunk build
> http://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/latest-trunk/  given
> that bug 265172 was fixed in June? 
> 

Was I supposed to install the browser.xpi found there? Because after I did that Firefox wouldn't even run until I uninstalled it and deleted the directories from Program Files and Application Data, then installed again. I'm not sure what SeaMonkey is but it didn't start either. Apparently js3250.dll and something else (nsp4.dll?) were not found.

Comment 6

[Wayne Mery (:wsmwk)]

Xuan 

(reporter), what do you see with a trunk build??

HyperHacker - firefox is http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/firefox-3.0a1.en-US.win32.installer.exe
do you see the bug with this?

Comment 7

[HyperHacker]

(In reply to comment #6)
Just tried it with my test case now and the bug seems to be gone. After ~10 hours of hibernation, the text is still blinking as normal and CPU usage is nearly zero.

Comment 8

[Adam Guthrie]

HyperHacker, can you also test on a branch build? http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla1.8/firefox-2.0b2.en-US.win32.installer.exe

Comment 9

[Xuân Baldauf]

Hello Wayne,

I'm sorry, I do not have the time to check wether the bug is now fixed. If HyperHacker thinks that the bug is fixed, I may well believe this (until I encounter the bug again). So I opt for closing this bug as fixed. :-)