Closed Bug 735141 Opened 13 years ago Closed 13 years ago

Bottom of tall image within scrollable div not drawn until text below image is in view

Categories

(Core :: Web Painting, defect)

Product:
Core
Component:
Web Painting
Version:
13 Branch
Platform:
x86_64
All
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla14
Tracking Flags:
Tracking Status
firefox13 + verified

People

(Reporter: zwol, Assigned: roc)

References

Details

(Keywords: regression, Whiteboard: [qa!])

Attachments

(2 files)

test case
504 bytes, text/html
Details
fix
2.96 KB, patch
tnikkel
: review+
akeybl
: approval-mozilla-aurora+
Details | Diff | Splinter Review
Attached file test case —
The attached test case contains a scrollable div, containing an image (just a big maroon rectangle) that is taller than the fixed height of the div, and text on either side of it. Make the browser window big enough that the entire div is visible, then scroll it up and down. When I do this, scrolling down from the top, the part of the image that was below the bottom of the container is not drawn until the text below the image scrolls into view; scrolling up from the bottom, the part of the image that started above the top of the container is not drawn until the text above the image is also visible. If the window loses input focus, any missing part of the image is also redrawn (AFAIK this still causes a total repaint, so it's not surprising). This seems to be peculiar to scrollable containers; it does not happen if it's the entire <body> being scrolled (or perhaps I should say, it does not happen if the scrollbar belongs to the entire content area). It may also be specific to Linux and/or my video drivers; however, disabling layer acceleration does not make the problem go away.
Oh, I should have said, this happens for me with a debug build of http://hg.mozilla.org/mozilla-central/rev/dfcb11712ec2 . It does NOT happen with Firefox 10 on the same machine. I have not tried anything in between.
Does not happen for me with 11.0 (latest beta) either, but that's on my Mac.
One last addendum: it must be a bitmap image; it does not happen with <div style="width:300px;height:800px;background:#800"></div> in place of the <img>.
Regression window(m-c), Works: http://hg.mozilla.org/mozilla-central/rev/a853f4017192 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0a1) Gecko/20120216 Firefox/13.0a1 ID:20120216031231 Fails: http://hg.mozilla.org/mozilla-central/rev/31fa580e684c Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0a1) Gecko/20120216 Firefox/13.0a1 ID:20120216024649 Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=a853f4017192&tochange=31fa580e684c Regression window(m-i), Works: http://hg.mozilla.org/integration/mozilla-inbound/rev/04caa247e11a Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0a1) Gecko/20120215 Firefox/13.0a1 ID:20120215195653 Fails: http://hg.mozilla.org/integration/mozilla-inbound/rev/db2216c57498 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0a1) Gecko/20120215 Firefox/13.0a1 ID:20120215201853 Pushlog: http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=04caa247e11a&tochange=db2216c57498 Suspected: 56c8584839b3 Robert O'Callahan — Bug 727661. We should only optimize ThebesLayers to ColorLayers or ImageLayers for brand-new layers (ThebesLayers with no currently valid data). Otherwise we risk ColorLayers being a deoptimization if there is valid content in the layer that doesn't happen to be visible but might become visible later, or if the layer contents are only temporarily a solid color and will soon need a buffer again. r=tn
Blocks: 727661
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: regression
OS: Linux → All
Version: unspecified → 13 Branch
This is a regression in 13, so we'd definitely consider taking a fix on Aurora. That being said, I don't see a need to track for the release as it's not yet clear that this testcase represents a common use case on the internet.
Assignee: nobody → roc
tracking-firefox13: ? → -
I set the flag on this bug because it had a simple testcase. No doubt Zack reduced it from something he came across. Bug 733337 also regressed from the same patch and Stuart mentioned a page he came across that was likely caused by the same bug on irc which we didnt file because I think it was likely to be fixed by one of these two bugs. So I think this is common.
tracking-firefox13: - → ?
The test case here was originally meant to be the minimal test case for a completely different bug involving horizontal box sizing. That bug has so far been unreproducible away from the computer where it was first spotted, but I noticed this bug while playing with the test case. So I can't say that I have seen this bug in the wild.
Ah, okay. Well the two other examples I mentioned were 'from the wild' so to speak.
Attached patch fix — — Splinter Review
Attachment #607062 - Flags: review?(tnikkel)
Comment on attachment 607062 [details] [diff] [review] fix I knew it was something like this, but didn't see it when I looked over the code before.
Attachment #607062 - Flags: review?(tnikkel) → review+
Backed out due to test failures: https://hg.mozilla.org/integration/mozilla-inbound/rev/07ac03710f04 The Mac test failure is just a detail of scrollbar rendering. I can make that go away by making the test use overflow:hidden. The Android failures don't make any sense; the image is a different color in test vs reference. I'll disable the test on Android.
https://hg.mozilla.org/mozilla-central/rev/9ce5ce7ac5a6
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla14
Comment on attachment 607062 [details] [diff] [review] fix Review of attachment 607062 [details] [diff] [review]: ----------------------------------------------------------------- Fix regression that landed on Aurora. Risk analysis: very simple code change, very bad regression.
Attachment #607062 - Flags: approval-mozilla-aurora?
Comment on attachment 607062 [details] [diff] [review] fix [Triage Comment] Since we've gotten reports of this bug externally and we now have a low risk fix in hand, we'll track for 13 and approve for Aurora uplift.
Attachment #607062 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Whiteboard: [qa+]
Verified fixed on Firefox 13b2: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20100101 Firefox/13.0 Mozilla/5.0 (X11; Linux i686; rv:13.0) Gecko/20100101 Firefox/13.0 Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:13.0) Gecko/20100101 Firefox/13.0
Status: RESOLVED → VERIFIED
status-firefox13: fixed → verified
Whiteboard: [qa+] → [qa!]
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

Creator:
Created:
Updated:
Size: