Black horizontal stripes/lines after zooming in and scrolling down in this case




Layout: View Rendering
10 years ago
10 years ago


(Reporter: Martijn Wargers (dead), Assigned: roc)



Windows XP
Bug Flags:
blocking1.9 +

Firefox Tracking Flags

(Not tracked)




(7 attachments)



10 years ago
Created attachment 293765 [details]

Maybe related to bug 382961.

See testcase, to reproduce the bug:
- Load the testcase, press ctrl-+ 4 times to zoom in
- scroll down

Expected result:
- No black stripes should be seen

Actual result:
- Black horizontal stripes over the place where the iframes are.

Note that after pressing 2 times ctrl-+, I already see a horizontal stripe appearing. (apparenlty, it also happens after 2 times zooming in)

Comment 1

10 years ago
I'm also seeing white stripes/lines on this site after scrolling on the left advertisement iframe (no need to zoom in):
Might be related to this bug.

Comment 2

10 years ago
Or just go to and scroll the page.
(Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b4pre) Gecko/2008022604 Minefield/3.0b4pre)


10 years ago
Flags: blocking1.9?


10 years ago
Flags: tracking1.9? → blocking1.9?
Don't see it on Mac. Maybe Windows only?

Comment 4

10 years ago
Could be, I only have access to Windows.
Furthermore, it only happens in the 'Ads by Google' frame on pages, but it is not always there (probably rotating with other ads). 

Comment 5

10 years ago
It happens intermittently for me, sometimes I see it happen a lot and then not anymore, using the same testcases, sites.

Comment 6

10 years ago
I could attach more (unminimized) testcases that also show the issue, but I doubt those would show the bug on Mac.

Comment 7

10 years ago
Created attachment 306281 [details]

Another testcase, that shows the issue for me. No need to zoom in or out. Every second iframe shows the black stripes for me when scrolling.
Yeah, that testcase works fine on Mac, breaks on Windows.

I wonder if this is related to bug 376124.

Comment 9

10 years ago
Ok, let's hope the patch in bug 376124 fixes this.
Depends on: 376124
Flags: blocking1.9? → blocking1.9+
Priority: -- → P2
That patch doesn't seem to fix this :-(.
Created attachment 306708 [details]
testcase 3

This testcase is fairly simple and shows the problem on load, no zooming or scrolling required --- there's a black line at the top of the IFRAME.
Created attachment 306973 [details]
even better testcase

This testcase shows the bug on Mac. There's a row of white pixels at the top of the IFRAME.
Okay, the problem here is that our "offset to the root" has user-space y of -10.5. We do UserToDevicePixelSnapped, that gives us -10. The problem is that the widget has been positioned at a y-offset of 11, not 10. So inverting the sign of the offset to the root before snapping, so it's consistent with how we round the offsets of widgets, should fix this.
Created attachment 306984 [details] [diff] [review]

This is actually a regression from the fix for bug 417967, the fix there was wrong.

The correct way to get things pixel-aligned is not to add an extra translation based on snapping. The logic in nsViewManager::Refresh should already be adequate to get things pixel-aligned, because we translate by ViewToWidgetOffset which is the difference in appunits between the view top-left and the (rounded) widget top-left.

The actual problem causing bug 417967 is that ViewToWidgetOffset always returns (0,0) for the root view of a subdocument, but that is incorrect when the subdocument is positioned at a fractional offset. As indicated in the comments in this patch, the true ViewToWidgetOffset for the root view should be the same as for its parent view which is the inner view of nsSubdocumentFrame. The reason for this discrepancy is that the root view's widget is not positioned by nsView::CalcWidgetBounds like all other views' widgets.

This patch fixes the testcases in this bug and does not regress bug 417967. Acid3 (reportedly regressed by 417967) also works fine.

I wish we could automatically test this stuff but AFAIK we'd need significant improvements in the infrastructure. drawWindow won't work because we need to paint via a child document's widget *and* have the drawing rooted by the outer document's viewmanager.

I am SO looking forward to compositor which will simplify this code out of existence.
Attachment #306984 - Flags: superreview?(bzbarsky)
Attachment #306984 - Flags: review?(bzbarsky)
Whiteboard: [needs review]
> Acid3 (reportedly regressed by 417967) also works fine.

I mean, it was reported that it had acquired a black line, and that is not apparent with this patch.
Comment on attachment 306984 [details] [diff] [review]

>+      // is always positioned at that iner view's top-left, and its


r+sr=bzbarsky with that
Attachment #306984 - Flags: superreview?(bzbarsky)
Attachment #306984 - Flags: superreview+
Attachment #306984 - Flags: review?(bzbarsky)
Attachment #306984 - Flags: review+
Whiteboard: [needs review] → [needs landing]
checked in
Last Resolved: 10 years ago
Resolution: --- → FIXED
Whiteboard: [needs landing]


10 years ago
Duplicate of this bug: 420172
verified fixed using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b5pre) Gecko/2008031004 Minefield/3.0b5pre. I verified using all of the test cases in the bug.

Comment 20

10 years ago
Created attachment 311816 [details]
screenshot of black bars 

I'm not certain if this is simliar or not to Bug 399435, but I'm seeing this bug appear in Firefox 3.0 Beta 5 and I was hoping it was fixed. Is this a new bug or an old  bug that was supposedly fixed?

Comment 21

10 years ago
Created attachment 311817 [details]
screenshot of missing lines when scrolling downward in gmail

I'm not certain if this is related to the black bars or lines when scrolling downward, but rows are failing to render in gmail on scrolling downward in Firefox  3.0 B5 rc1.
Aharon, please file a new bug for that with steps to reproduce, and CC me and, thanks!
You need to log in before you can comment on or make changes to this bug.