Closed Bug 197065 Opened 21 years ago Closed 21 years ago

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

Categories

(Core :: Web Painting, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: jacquetc.mozilla, Assigned: roc)

References

()

Details

(Whiteboard: [fix])

Attachments

(1 file)

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 http://jacquetc.free.fr/mozilla/bug1/
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
http://jacquetc.free.fr/mozilla/bug1/screenshot.png

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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
-> all/all (seeing this on OS X 1.3RC build)
OS: Linux → All
Hardware: PC → All
Confirming Moz 1.3RC Windows
Attached patch Proposed patchSplinter Review
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 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 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
problems.
> 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
anymore?
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.
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
Component: Layout: View Rendering → Layout: Web Painting
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: