bad display of a background image in a block with "position: absolute" when dynamically changing the height of this block




Layout: View Rendering
15 years ago
15 years ago


(Reporter: Christophe Jacquet, Assigned: roc)



Firefox Tracking Flags

(Not tracked)


(Whiteboard: [fix], URL)


(1 attachment)



15 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030311
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030311

I have a block with "position: absolute" and a background image aligned to the
bottom right corner. When I decrease the height of this block (by collapsing one
of its child blocks through dynamic modification of CSS in Javascript), and then
give it its original size, its background does not get repainted correctly. A
part of the background image appears twice on the screen.

Reproducible: Always

Steps to Reproduce:
1. Load
2. Click once on "Collapse/Expand" (to collapse the green block)
3. Click another time on "Collapse/Expand" (to re-expand the green block)

Actual Results:  
The background image of the bounding (blue-bordered) box has not been repainted
correctly. The image painted when the block was collapsed remains on the screen.
Thus, the word "RIGHT" appears twice on the screen.

The problem appears on the screenshot at

Expected Results:  
The whole background of the bounding box should be repainted, and not only the
part that has grown. The display should be the same as after loading the page.
In particular, the word "RIGHT" should apear only once.

Actually, when I drag the window around or force it to be refreshed by any
means, it gets repainted correctly. So I think that the internal layout of the
page is OK, but a repaint should be triggered upon expansion of the block.

Look at the HTML code for more details. I think that the interesting CSS
properties of the bounding block are the following:
  background-repeat: no-repeat;
  background-image: url("testmoz.png");
  background-position: right bottom;
  position: absolute;

The problem does not arise when I delete the "position: absolute" atrribute.
Confirmed on current linux trunk.
Ever confirmed: true

Comment 2

15 years ago
-> all/all (seeing this on OS X 1.3RC build)
OS: Linux → All
Hardware: PC → All
Confirming Moz 1.3RC Windows
Created attachment 117809 [details] [diff] [review]
Proposed patch

proposed fix.

This changes the behavior of the CheckInvalidate function. We're now more
explicit about what it does (see the comment). And we take care of some cases
that the function was missing.

I removed the reflow command checks from the function. I don't see why it's
necessary to detect a style change; the style change hints for the changed
property (e.g., 'border') should take care of any invalidation.
Comment on attachment 117809 [details] [diff] [review]
Proposed patch

I think jkeiser created this function.
Attachment #117809 - Flags: superreview?(dbaron)
Attachment #117809 - Flags: review?(jkeiser)
Note that the patch isn't 'optimal'; there are lots of ways we could reduce
invalidation by checking more style information or by invalidating smaller
areas. But I'm unconvinced that such optimization is necessary.
Whiteboard: [fix]

Comment 7

15 years ago
Comment on attachment 117809 [details] [diff] [review]
Proposed patch

This is certainly a lot simpler and more readable, so as long as it doesn't
regress pageload time I'm fine with it.
Attachment #117809 - Flags: review?(jkeiser) → review+

Comment 8

15 years ago
Comment on attachment 117809 [details] [diff] [review]
Proposed patch

Hmm, what about backgrounds that tile?	And non-percent backgrounds that are
aligneed at the bottom right?  I don't see how this will fix all the background
> And non-percent backgrounds that are aligneed at the bottom right?

They get translated to percentages in the style system, as far as I can tell.

> what about backgrounds that tile?

Any part of the background that falls outside the difference between the old and
new frame areas will be repainted by the caller. That's what the contract for
CheckInvalidateSizeChange says. We only have to worry about the case where
changing the frame size requires the entire background to be repainted.
Does this handle things like the case where we used to have borders, but don't
Comment on attachment 117809 [details] [diff] [review]
Proposed patch

(Or is that handled by the style change system, which makes a border change a
reflow *and* repaint?)	Anyway, sr=dbaron if you think there's a good answer to
my question.
Attachment #117809 - Flags: superreview?(dbaron) → superreview+
Yes. Style changes to the borders and background and so on are handled by the
style system hinting (which should force a VISUAL change, meaning full repaint
of the frame). All this patch is for is size changes where the actual styles
didn't change.
*** Bug 199812 has been marked as a duplicate of this bug. ***
Checked in.
Last Resolved: 15 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.