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)
Core
Web Painting
Tracking
()
RESOLVED
FIXED
People
(Reporter: jacquetc.mozilla, Assigned: roc)
References
()
Details
(Whiteboard: [fix])
Attachments
(1 file)
10.47 KB,
patch
|
john
:
review+
dbaron
:
superreview+
|
Details | Diff | Splinter Review |
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.
Comment 1•21 years ago
|
||
Confirmed on current linux trunk.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 2•21 years ago
|
||
-> all/all (seeing this on OS X 1.3RC build)
OS: Linux → All
Hardware: PC → All
Comment 3•21 years ago
|
||
Confirming Moz 1.3RC Windows
Assignee | ||
Comment 4•21 years ago
|
||
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.
Assignee | ||
Comment 5•21 years ago
|
||
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)
Assignee | ||
Comment 6•21 years ago
|
||
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•21 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•21 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 problems.
Assignee | ||
Comment 9•21 years ago
|
||
> 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+
Assignee | ||
Comment 12•21 years ago
|
||
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.
Assignee | ||
Comment 13•21 years ago
|
||
*** Bug 199812 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 14•21 years ago
|
||
Checked in.
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
Updated•6 years ago
|
Component: Layout: View Rendering → Layout: Web Painting
You need to log in
before you can comment on or make changes to this bug.
Description
•