Closed Bug 110113 Opened 21 years ago Closed 19 years ago

Assigning background image to body & html: CPU pegged, neither background displayed


(Core Graveyard :: GFX, defect, P1)



(Not tracked)



(Reporter: liorean, Assigned: smontagu)



(Keywords: perf, testcase)


(2 files, 1 obsolete file)

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.5) Gecko/20011011
BuildID:    2001101117

I made a homepage with separate background images assigned to html and body
element to see how ie6 and moz respectively behaved when doing so. I found moz
certainly didn't behave as I'd wanted.

I took screenshots of the results to display the problem here:
Background image on body:
Background image on html:
Background image on both:

CPU usage while trying to use background images on both elements quickly rises
to 100%.

Interesting to note is that when you change the link tag's href attribute to
another css looking the same but with different images, those images are
rendered for an instance - just a flash really - then the background colour is

Also noted at those changes (even appearing when both background images are
commented out), is that when you have swapped the background colours used in the
original css, only body background colour renders. Does the same no matter how I
define colour (#rrggbb or rgb(#,#,#) makes no difference). I believe this might
be an entirely different bug though.

Reproducible: Always
Steps to Reproduce:
1. Write a simple homepage (xhtml1.0 strict with dtd) which use the css included
2. Display in Mozilla browser (0.9.5 talkback enabled windows build)

Actual Results:  CPU pegged, neither background image displayed.
CPU usage when background image on both:
CPU usage when background image on body:

Expected Results:  Both images rendered, like ie6 does.

CPU running normally.

Stylesheet used:

	background-color: rgb(251,215,125);
	background-image: url(mozilla.jpeg);

	background-color: rgb(125,215,251);
	background-image: url(netscape.jpeg);

	color: rgb(255,255,255);

When I tested either one background image, I simply commented one rule or the other.
In my test the style was placed in a .css file included using a link tag. I
haven't tested importing it, nor have I tested writing it directly in a style tag.
David, I can't reproduce this problem... Is there a publicly available testcase
that you can reproduce this on?
Keywords: perf
The page I used has been submitted as attachment. I moved the css into a style
tag and checked on my Mozilla - same effects.
Attachment #57934 - Attachment is obsolete: true
I can reproduce this one out of every three page loads or so with that testcase...
Ever confirmed: true
Looked at your testcase (sorry about forgetting to change into valid URL's...).

At first it didn't load the images, but pegged the CPU nonetheless.
Then I looked at the source and looked at both images, and then returned.
Now sometimes (notably after pressing back or forward button in menubar but
before Mozilla had left the page) the images appeared. CPU was still pegged.

Cashing problem?
That's similar to what I was seeing... I could never reproduce the problem on
first load, but a shift-reload would usually cause it...
Boris, David

this would then be a good testcase for the cpu usage and background images that
appear in other bugzilla bugs? ie: bug 99924 for instance.
2002-2-21-03 w2k, bug 122996 appears to have fixed several scrolling background
image bugs with 100% CPU, I'm not seeing any slow scrolling anymore on many bugs.

the 3 URLS listed here in the description don't peg the CPU anymore, it looks
fixed.  Please confirm.
*** Bug 130055 has been marked as a duplicate of this bug. ***
Is this related to bug 130027 ?
Looked at the testcase in 0.9.9, Win2k.

Works for me.
Still 100% CPU with 0.9.9+ (2002033109), Win95
Hmm, had a look again in 0.9.9. I didn't wait long enough last time, it seems.
First it quickly goes up to 100% and back again, then it goes up again, but not
until a a few seconds have passed.
related: bug 98626 ?
This appears to be true for Moz 1.2b, including Phoenix 0.2->0.3, on WinXP. 

I've written a bare-minimum test case.  It includes explanations

A background-image is the only property required to cause the cpu pegging, but
an image must be to _both_ HTML and BODY.  It need not be the same image. 
background-[repeat,color,position,attachment] do not affect this bug.

Additionally, this bug does not seem to occur if the html is a local file and
the CSS points to images with fully qualified address.  A relative URL seems to
be required.  Possibly a network reflow issue.

Bug 122976 may be related or duplicate.

This is an easy bug to invoke. demonstrates a common way to
run into the issue; solved by encasing body content in a div and moving the
background-image structure one down the heirarchy; undesirable as the markup is
non-semantic, extranious, and complicates the box model.
A few more data points:

I can reproduce the 100% cpu usage on Win2k using 1.1 and nightly build
2002111308, using the testcase supplied (second attachment, #57937). No
reloading is needed to peg the CPU up high.

I *cannot* reproduce this on Linux using 1.2b or a nightly from around 20021110.
So it looks like this is win32-specific. Can anyone with a Mac reproduce this?

The summary probably wants to get changed, as both backround images are showing
up, it's just the CPU usage that is the hassle.
windows only, ->GFX
Assignee: dbaron → kmcclusk
Component: Style System → GFX Compositor
Bug 173328 seems related to this.
Keywords: testcase
*** Bug 146689 has been marked as a duplicate of this bug. ***
Using the same image but with different URL strings causes this bug as well…

See bug 146689
*** Bug 173328 has been marked as a duplicate of this bug. ***
*** Bug 123155 has been marked as a duplicate of this bug. ***
I can reproduce this on Linux using 1.2.1.
OS: Windows 2000 → All
Attached file Test case
This test was originally constructed for bug 123155.
-> Simon M.
Assignee: kmcclusk → smontagu
Priority: -- → P1
Target Milestone: --- → Future
I haven't done any code digging, but it looks like a case of circular reflow. 
Perhaps the image in the HTML is causing the image in the BODY to repaint, which
causes the image in BODY to repaint, which causes the image in HTML to repaint,
etc, etc.

One thing is for sure, the images are continually drawing themselves.
Talking to dbaron on IRC he doesn't think this is related to reflow.
Mozilla 1.3, Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3)
Gecko/20030312, Windows XP Pro, Build 2600.xpsp1.020828-1920

Dell OPTIPLEX GX50, Celerron 1.2GHz, 256 MB RAM, Intel 82810E Graphics Controller

Maybe these pages are related to this bug:

See or
(or any other page, for that matter) for pages that cause intense
CPU/kernel thrashing

The hiwaay pages scroll fine in Opera 7.03, IE 6, Amaya 7.2 & even Netscape 2.02(!).
I propose upgrading this bug's Severity to critical

      This bug can crash a user on Windows using Netscape builds/Mozilla builds
or the Thunderbird builds. Any user on those systems can be affected if they are
sent an email message with a tiled background.
This raises the severity of the bug from 'normal' to 'critical' as it actually
can be used as an exploit against such users to crash them at will.

Steps to reproduce
      Create a new email message (or news message as this bug surfaces there as
well) Using HTML formatting.
      For Background select an image (for purposes of demonstration the larger
the better). Add in your text (tho this is superfleous). Send it to yourself (or
to any other Windows user if you really want their attention)
      Message is opened, CPU usage goes to 100% and dependent on whatelse is
running, crashes the user. In most cases the user wouldnt have a clue what happened

As extant, this bug seems to affect those on Windows operating systems (and
possibly Linux) but not Macintosh Systems. It may be related to the Patbt fix as
described in the verified fixed 122996

I loaded up attachment 57937 [details] in the current 1.4's. In Win, I got "done" almost
immediately, but never saw anything but a blue background and a half of a
Mozilla banner. In Linux, top seems to indicate that Mozilla is overloading X,
with X running 60-70%, & Mozilla most of the rest of the CPU, both initally, &
over 10 minutes later. Same viewport content. X'ing the tab rescued the CPU. In
OS/2, again same viewport content, with CPU pegged at 100%. X'ing the tab didn't
rescue the CPU. I had to close Mozilla entirely to get the CPU back to normal.

Normal severity just doesn't seem appropriate here.
I think this is the problem with Mozillazine's AfterDark stylesheet. Noticed
this first when I started using Firebird build 2003-08-10 (win32) and tried the
new stylesheet selector. After selecting the AfterDark style, the CPU usage got
pretty high and I couldn't scroll the page anymore. Later I found that the
scrolling problem occurs only if I had smoothscrolling enabled.

Anyway, I made some testcases and discovered that if the images are the same
type, the cpu usage is normal, but if there is a combination of gif+png, gif+jpg
or png+jpg the cpu usage gets very high. 

The testcases are here, if interested:
I don't believe that this is image-format related.

This bug is perfectly reproducible with the testcase labeled "Test case
with valid image urls" which uses two *different* gifs (i.e. same
type but not the same image).
In the test case you mentioned, the other gif is transparent. That seems to bork
the CPU too. Updated my test cases.
Depends on: 219302
Fixed by patch in bug 219302
Closed: 19 years ago
Resolution: --- → FIXED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.