canvas background fixup causes weird incremental repaint




CSS Parsing and Computation
17 years ago
17 years ago


(Reporter: dbaron, Assigned: Marc Attinasi)


({css1, regression})

css1, regression

Firefox Tracking Flags

(Not tracked)





17 years ago
Something related to the canvas background fixup or body fixup rule is working
strangely in some cases.

 * load

 * **some of the time**, the correct display (dark green around edges) flashes,
but is then replaced by light green where the dark green should be.  Sometimes
it works correctly.  It becomes correct again after an expose event.

 * Light green BODY, dark green HTML (in margins of BODY and below bottom of BODY)

 * MacOS 9.0.4 Mozilla 2000-09-22-20


17 years ago
Keywords: css1

Comment 1

17 years ago
This sounds like it could be a mac-specific rendering issue (I cannot see it on 
NT or Linux, and David did report it as a mac-only bug).

Reassigning to rendeing team to investigate.
Assignee: attinasi → kmcclusk

Comment 2

17 years ago
NOTE: I just saw this on WinNT - it is really strange because I exposed the 
window which was partially obscured by my mail window, and the outter are was 
mostly light green (the newly exposed part anyway) and then I hid it again and 
re-exposed it an it repainted correctly. Also, if you resize it after the 
initial exposure it updates correctly.

I believe the problem is in the html.css file, the rule:

:viewport, :viewport-scroll, :canvas {
  display: block;
  background-color: inherit;

is causing the problem. If yuo remove 'background-color: inherit' it works fine. 
I believe that this is a problem with the style resolution battling with the 
body fixup rule.

Taking back now...
Assignee: kmcclusk → attinasi

Comment 3

17 years ago
Accepting and updating the platform fields, adding regression kwd.
Keywords: regression
OS: Mac System 9.0 → All
Priority: P3 → P2
Hardware: Macintosh → All
Target Milestone: --- → M18

Comment 4

17 years ago
OK, after another 15 minutes of playing with this it is clear that those rules 
are NOT the problem. This bug is just tempermental and I was not being thorough 
enough. Please disregard my prior comment (2000-09-25 10:56).
FWIW, without those rules it stops using the default background colours.
Hey, if these non-standard extensions were documented somewhere, I could have
been more sure of what I was doing when I edited the rules with those strange
and interesting pseudo-classes, ok... ;-)

Comment 6

17 years ago
David, do you have any idea when this started happening? I cannot seem to repro 
it in a build from 9/19, but easily can from a build of 9/22 (as you reported 
it). Have you seen this before 9/22?

Comment 7

17 years ago
I reported it the first time I saw it, but I didn't test that page for months
before I saw it.

Comment 8

17 years ago
Nominating for RTM since this is really ugly and will probably show up on the
BoxAcidTest as well.
Keywords: rtm

Comment 9

17 years ago
Popping up a content-menu over the HTML are and dismissing by clicking in the
BODY will reporduce this problem quite reliably. Covering and exposing the
window will also reporduce it, but much less reliably.
*** Bug 54660 has been marked as a duplicate of this bug. ***

Comment 11

17 years ago
CC'ing Kevin to check out. Thanks, Kevin.

Comment 12

17 years ago
CCd myself because the rule above and the origin of the canvas background are of 
interest to me (bug 19329).
It's been said that this *may* show up on the Box Acid Test. Can anyone confirm

Comment 14

17 years ago
I cannot check the Box Avid Test because is down right now. I'll
keep trying.

Comment 15

17 years ago
Actually, I cannot reproduce this at all anymore. I tested David and Ian's pages:

and a modified Box Acid Test page (since the original is down) at:

using the context-menu technique and the random hide/show window technique and I
cannot get the bug to show.

Marking WORKSFORME - please reopen if you can still reproduce it. (I'll also
check the Box Acid Test when it is up again.)
Last Resolved: 17 years ago
Resolution: --- → WORKSFORME
I couldn't reproduce this yesterday either, but did not check this thoroughly.
I wouldn't say it was stop ship, even if it did affect the box acid test. This
is (was) a very minor bug IMHO.

BTW, Marc: the box acid test is at:
Netscape's standard compliance QA team reorganised itself once again, so taking 
remaining non-tables style bugs. Sorry about the spam. I tried to get this done 
directly at the database level, but apparently that is "not easy because of the 
shadow db", "plus it screws up the audit trail", so no can do...
QA Contact: chrisd → ian
Reassigning QA to reporter. I could never reproduce this much on the given 
pages anyway, so I couldn't really verify it.
QA Contact: ian → dbaron
You need to log in before you can comment on or make changes to this bug.