Background is not updated past body content

RESOLVED FIXED in mozilla0.9.9


19 years ago
10 years ago


(Reporter: roysinclair, Assigned: kmcclusk)


Windows 2000

Firefox Tracking Flags

(Not tracked)



(3 attachments)



19 years ago
From Bugzilla Helper:
BuildID:    2000092908

I have a javascript which is used to scroll the background image on the page. 
This script animates the background image but the background image isn't 
repainted on the whole of the browser window, it stops updating the background 
at the bottom of the page element that consists of the lowest rendered page 
content (excluding the background).

Reproducible: Always
Steps to Reproduce:
1. Use attached demo page and image

Expected Results:  The whole background area of the page in the window should 
be updated.

Comment 1

19 years ago
Created attachment 19272 [details]
Page with script demonstrating the problem

Comment 2

19 years ago
Created attachment 19273 [details]
Image used in demo page

Comment 3

19 years ago
The build you test with is soon two months old.
Please follow bug reporting guidelines and see if the bug can be reproduced in a
recent build.
Testing this with linux 2000111508 shows the image all over the page, regardless
of how i resize it.

Comment 4

19 years ago
Build 200111508 fails with "An unknown error has occurred (804b0005)" in the 
status line.  It doesn't show the problem because it isn't executing the 
javascript code on the page.  The background on the whole page should be moving 
to the left and down.  I also tried nightly builds back to 2000111220 which no 
longer shows the "unknown error" message but also doesn't seem to be running 
the javascript.

The M18 build (2000101014) shows the problem.

Comment 5

19 years ago
the "unknown error" is another bug.
Seems we're left with a potential JS error here then. But i compared to how this
acts/looks in NC4.75, and it looks and behaves just like in Mozilla.
Meaning NC 4.75 doesn't execute the JS code either.
Which version can you confirm the code in the uploaded attachment work with?

Comment 6

19 years ago
This is a logic error in the script but since it is legal javascript it does not
appear in the javascript console.

The BGScroller constructor saves the name of the object in myObjectVarName and a
reference to the object in myObject.

The method BGStart compares the object reference myObject against the string
value of an object's name.  It should either compare myObjectVarName against the
string value of the object's name or it should compare the myObject against the
a reference to the object.

I have not looked for further errors in this script.

Marking Invalid

Last Resolved: 19 years ago
Resolution: --- → INVALID

Comment 7

19 years ago
The problem is a defective *comment* that still reflects an earlier attempt at 
getting the script to function.  I didn't want to say this but in order to see 
the script operate properly you need to bring the page up in Internet Explorer 
4.0 or later.

Resolution: INVALID → ---

Comment 8

19 years ago
Confirm on trunk build 2000-12-04-04/Win2k. Attaching a new test case that can
be viewed from the attachment.
Ever confirmed: true

Comment 9

19 years ago
Created attachment 20230 [details]
Demonstration page (does not require external image)


18 years ago
Assignee: kmcclusk → dcone

Comment 10

18 years ago
Reassigning to Don.
Tiled background image rendering problem.

Comment 11

18 years ago
Seems the certain parts of the window are not being invalidated.. if I cover and  
uncover the window.. the background is drawn in the correct location. Back to 
Kevin for triage.
Assignee: dcone → kmcclusk


18 years ago

Comment 12

18 years ago
Setting milestone to mozilla1.0
Target Milestone: --- → mozilla1.0

Comment 13

18 years ago
Clearing milestone.
Target Milestone: mozilla1.0 → ---

Comment 14

18 years ago

In ApplyRenderingChangeToTree there is code which invalidates the extent of the
frame as the result of the attribute change:

if (! view) { // if frame has view, will already be invalidated
      // XXX Instead of calling this we should really be calling
      // Invalidate on on the nsFrame (which does this)
      const nsStyleOutline* outline;
      aFrame->GetStyleData(eStyleStruct_Outline, (const nsStyleStruct*&)outline);
      nscoord width;
      if (width > 0) {
        invalidRect.Inflate(width, width);
      nsPoint frameOrigin;
      invalidRect -= frameOrigin;
      invalidRect += viewOffset;
      viewManager->UpdateView(parentView, invalidRect, NS_VMREFRESH_NO_SYNC);

The frame instance that is invalidated as the background is moved is
nsHTMLContainerFrame.  The height for this frame doesn't cover the entire
document so only the top part of the body is invalidated.

Marc: When the document.body's backgroundPosition attribute is set it looks like
the nsHTMLContainerFrame is reponsible for invalidating. This seems wrong, since
it doesn't cover the entire window. Should some other frame which covers the
entire window be invalidated instead?

Target Milestone: --- → Future


18 years ago
Target Milestone: Future → mozilla0.9.9
I suspect this is either fixed by my checkin for bug 116161 yesterday or the
remaining issues are a duplicate of bug 63863.

Comment 16

17 years ago
Looks like David Baron's fix for bug 116161 also fixed this bug. I don't see any
problems with cvs  pull from today on WINXP.
Last Resolved: 19 years ago17 years ago
Resolution: --- → FIXED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.