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

Status: VERIFIED FIXED

(Core :: Web Painting, defect, P2)

Description

[Martijn Wargers (dead)]

Attachment: testcase

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

[Martijn Wargers (dead)]

I'm also seeing white stripes/lines on this site after scrolling on the left advertisement iframe (no need to zoom in):
http://www.beursduivel.be/Winst_Wachovia_verdampt_door_afschrijvingen-43667.news
Might be related to this bug.

Comment 2

[Alfred Kayser]

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

Comment 3

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Don't see it on Mac. Maybe Windows only?

Comment 4

[Alfred Kayser]

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

Comment 5

[Martijn Wargers (dead)]

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

Comment 6

[Martijn Wargers (dead)]

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

Comment 7

[Martijn Wargers (dead)]

Attachment: testcase2

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.

Comment 8

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Yeah, that testcase works fine on Mac, breaks on Windows.

I wonder if this is related to bug 376124.

Comment 9

[Martijn Wargers (dead)]

Ok, let's hope the patch in bug 376124 fixes this.

Comment 10

[Robert O'Callahan (:roc) (email my personal email if necessary)]

That patch doesn't seem to fix this :-(.

Comment 11

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Attachment: 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.

Comment 12

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Attachment: even better testcase

This testcase shows the bug on Mac. There's a row of white pixels at the top of the IFRAME.

Comment 13

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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.

Comment 14

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Attachment: fix

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.

Comment 15

[Robert O'Callahan (:roc) (email my personal email if necessary)]

> 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 16

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 306984 [details] [diff] [review]
fix

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

s/iner/inner/

r+sr=bzbarsky with that

Comment 17

[Robert O'Callahan (:roc) (email my personal email if necessary)]

checked in

Comment 19

[Marcia Knous [:marcia]]

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

[Aharon]

Attachment: 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

[Aharon]

Attachment: 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.

Comment 22

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Aharon, please file a new bug for that with steps to reproduce, and CC me and [e-mail], thanks!