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

VERIFIED FIXED in Firefox 13

Status

()

Core
Layout: View Rendering
VERIFIED FIXED
6 years ago
5 years ago

People

(Reporter: zwol, Assigned: roc)

Tracking

({regression})

13 Branch
mozilla14
x86_64
All
regression
Points:
---
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(firefox13+ verified)

Details

(Whiteboard: [qa!])

Attachments

(2 attachments)

(Reporter)

Description

6 years ago
Created attachment 605285 [details]
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.
(Reporter)

Comment 1

6 years ago
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.
(Reporter)

Comment 2

6 years ago
Does not happen for me with 11.0 (latest beta) either, but that's on my Mac.
(Reporter)

Comment 3

6 years ago
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>.

Comment 4

6 years ago
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
tracking-firefox13: --- → ?

Comment 5

6 years ago
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: - → ?
(Reporter)

Comment 7

6 years ago
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.
Created attachment 607062 [details] [diff] [review]
fix
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+
https://hg.mozilla.org/integration/mozilla-inbound/rev/0fe31dd7bbc5
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://tbpl.mozilla.org/?tree=Try&rev=e55e982828a2
https://hg.mozilla.org/integration/mozilla-inbound/rev/9ce5ce7ac5a6
https://hg.mozilla.org/mozilla-central/rev/9ce5ce7ac5a6
Status: NEW → RESOLVED
Last Resolved: 6 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?

Updated

6 years ago
tracking-firefox13: ? → +
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+
https://hg.mozilla.org/releases/mozilla-aurora/rev/ed87206d099a
status-firefox13: --- → fixed
Flags: in-testsuite+
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!]
You need to log in before you can comment on or make changes to this bug.