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

RESOLVED FIXED in Future

Status

Core Graveyard
GFX
P1
normal
RESOLVED FIXED
16 years ago
8 years ago

People

(Reporter: David "liorean" Andersson, Assigned: smontagu)

Tracking

({perf, testcase})

Trunk
Future
x86
All
perf, testcase

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments, 1 obsolete attachment)

(Reporter)

Description

16 years ago
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.
David, I can't reproduce this problem... Is there a publicly available testcase
that you can reproduce this on?

Updated

16 years ago
Keywords: perf
(Reporter)

Comment 2

16 years ago
Created attachment 57934 [details]
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.
Created attachment 57937 [details]
Testcase with valid image urls
Attachment #57934 - Attachment is obsolete: true
I can reproduce this one out of every three page loads or so with that testcase...
Status: UNCONFIRMED → NEW
Ever confirmed: true
(Reporter)

Comment 5

16 years ago
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...

Comment 7

16 years ago
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

16 years ago
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. ***

Comment 10

16 years ago
Is this related to bug 130027 ?
(Reporter)

Comment 11

16 years ago
Looked at the testcase in 0.9.9, Win2k.

Works for me.

Comment 12

16 years ago
Still 100% CPU with 0.9.9+ (2002033109), Win95
(Reporter)

Comment 13

16 years ago
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

15 years ago
related: bug 98626 ?
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

15 years ago
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

Comment 18

15 years ago
Bug 173328 seems related to this.
Keywords: testcase

Comment 19

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

Comment 20

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

See bug 146689

Comment 21

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

Comment 22

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

Comment 23

15 years ago
I can reproduce this on Linux using 1.2.1.
OS: Windows 2000 → All

Comment 24

15 years ago
Created attachment 111553 [details]
Test case

This test was originally constructed for bug 123155.
-> Simon M.
Assignee: kmcclusk → smontagu
Priority: -- → P1
Target Milestone: --- → Future

Comment 26

15 years ago
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

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

Comment 28

15 years ago
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

14 years ago
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

14 years ago
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

14 years ago
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

14 years ago
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

14 years ago
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
Status: NEW → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → FIXED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.