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

Status: RESOLVED FIXED

(Core Graveyard :: GFX, defect, P1)

Description

[David "liorean" Andersson]

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: http://liorean.tripod.com/bugzilla/mozilla_body.png
Background image on html: http://liorean.tripod.com/bugzilla/mozilla_html.png
Background image on both: http://liorean.tripod.com/bugzilla/mozilla_both.png

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
displayed.

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
below.
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:
http://liorean.tripod.com/bugzilla/cpu_both.png
CPU usage when background image on body:
http://liorean.tripod.com/bugzilla/cpu_body.png

Expected Results:  Both images rendered, like ie6 does.
Example: http://liorean.tripod.com/bugzilla/ie_both.png

CPU running normally.



Stylesheet used:

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

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

a
{
	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.

Comment 1

[Boris Zbarsky [:bzbarsky]]

David, I can't reproduce this problem... Is there a publicly available testcase
that you can reproduce this on?

Comment 2

[David "liorean" Andersson]

Attachment: Testcase with css moved into style tag.

The page I used has been submitted as attachment. I moved the css into a style
tag and checked on my Mozilla - same effects.

Comment 3

[Boris Zbarsky [:bzbarsky]]

Attachment: Testcase with valid image urls

Comment 4

[Boris Zbarsky [:bzbarsky]]

I can reproduce this one out of every three page loads or so with that testcase...

Comment 5

[David "liorean" Andersson]

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?

Comment 6

[Boris Zbarsky [:bzbarsky]]

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...

Comment 7

[[not reading bugmail]]

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.

Comment 8

[[not reading bugmail]]

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.

Comment 9

[Christopher Aillon (sabbatical, not receiving bugmail)]

*** Bug 130055 has been marked as a duplicate of this bug. ***

Comment 10

[Markus Hübner]

Is this related to bug 130027 ?

Comment 11

[David "liorean" Andersson]

Looked at the testcase in 0.9.9, Win2k.

Works for me.

Comment 12

[Uwe Schröder]

Still 100% CPU with 0.9.9+ (2002033109), Win95

Comment 13

[David "liorean" Andersson]

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.

Comment 14

[John Levon]

related: bug 98626 ?

Comment 15

[John Christopher Jones]

This appears to be true for Moz 1.2b, including Phoenix 0.2->0.3, on WinXP. 
Gecko/20020929

I've written a bare-minimum test case.  It includes explanations
http://68.100.11.159:1090/~daelin/mozilla-canvas-bug/

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.  http://www.mynx.com 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.

Comment 16

[Mike Gratton]

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.

Comment 17

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

windows only, ->GFX

Comment 18

[Markus Hübner]

Bug 173328 seems related to this.

Comment 19

[Thamer Mahmoud]

*** Bug 146689 has been marked as a duplicate of this bug. ***

Comment 20

[Thamer Mahmoud]

Using the same image but with different URL strings causes this bug as well…

See bug 146689

Comment 21

[Thamer Mahmoud]

*** Bug 173328 has been marked as a duplicate of this bug. ***

Comment 22

[ArronM (:paper)]

*** Bug 123155 has been marked as a duplicate of this bug. ***

Comment 23

[Braden]

I can reproduce this on Linux using 1.2.1.

Comment 24

[Braden]

Attachment: Test case

This test was originally constructed for bug 123155.

Comment 25

[Kevin McCluskey (gone)]

-> Simon M.

Comment 26

[ArronM (:paper)]

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.

Comment 27

[Markus Hübner]

Talking to dbaron on IRC he doesn't think this is related to reflow.

Comment 28

[earthsound]

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 http://www.hiwaay.net/support/faq/index.cgi?view_category=1&catid=50 or
http://www.hiwaay.net/support/faq/index.cgi?view_category=1&catid=88
(or any other hiwaay.net 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(!).

Comment 29

[Dan Gall]

I propose upgrading this bug's Severity to critical

Reasoning:
      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

Comment 30

[Felix Miata]

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.

Comment 31

[viipale+bugzilla]

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: http://uggi.org/mozilla/bug110113/

Comment 32

[Thamer Mahmoud]

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).

Comment 33

[viipale+bugzilla]

In the test case you mentioned, the other gif is transparent. That seems to bork
the CPU too. Updated my test cases.

Comment 34

[Boris Zbarsky [:bzbarsky]]

Fixed by patch in bug 219302