Closed Bug 325384 Opened 19 years ago Closed 18 years ago

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

Categories

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

1.8 Branch
x86
Windows XP
defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 265172

People

(Reporter: baldauf--2015--bugzilla.mozilla.org, Unassigned)

References

()

Details

Attachments

(1 file)

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.
Assignee: general → events
Component: General → Event Handling
Product: Mozilla Application Suite → Core
QA Contact: general → ian
Version: unspecified → 1.8 Branch
Attached file Simple test case (deleted) —
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.
(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?
(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.
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?
(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.
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. :-)
Status: UNCONFIRMED → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
Status: RESOLVED → UNCONFIRMED
Resolution: FIXED → ---
Status: UNCONFIRMED → RESOLVED
Closed: 18 years ago18 years ago
Resolution: --- → WORKSFORME
Resolution: WORKSFORME → DUPLICATE
Summary: 100% CPU load after resume if page viewed contains blinking text → 100% CPU load after resume if page viewed contains blinking text, flash image
Component: Event Handling → User events and focus handling
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: