376124 - Random lines rendered when scrolling

Status: VERIFIED FIXED

(Core :: SVG, defect, P1)

Description

[hhh]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.4pre) Gecko/20070329 BonEcho/2.0.0.4pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.4pre) Gecko/20070329 BonEcho/2.0.0.4pre

When scrolling quickly, horizontal lines randomly appear and disappear.

Reproducible: Always

Steps to Reproduce:
1.Navigate to test URL
2.Scroll down quickly
3.
Actual Results:  
A line randomly appears

Expected Results:  
Page should render properly

Comment 1

[hhh]

Screenshot here...

http://forums.mozillazine.org/viewtopic.php?p=2823567#2823567

Comment 2

[gabe]

vista does not seem affected here

Comment 3

[Oliver Saier]

WFM (4/1 nightly on Linux)

Comment 4

[hhh]

I've stopped seeing this in the latest nightly...
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a4pre) Gecko/20070402 Minefield/3.0a4pre ID:2007040204 [cairo]

Comment 5

[Samuel Sidler (old account; do not CC)]

I'm sure this is a dupe of another (core) bug, but let's just resolve it as WFM since it's been fixed in the latest nightlies.

Comment 6

[hhh]

Seeing it badly in today's build, this needs to be reopened (see screenshot).

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a4pre) Gecko/20070409 Minefield/3.0a4pre ID:2007040904 [cairo]

Comment 7

[hhh]

Attachment: Screenshot

Comment 8

[Samuel Sidler (old account; do not CC)]

Hass, I still can't reproduce using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a4pre) Gecko/20070409 Minefield/3.0a4pre. Could this be a problem with your graphics card? Are you seeing this with other browsers or just Gecko-based ones? Do you see this on another machine or is it specific to one machine?

Comment 9

[hhh]

I haven't seen it with any other browser except trunk-cairo, and I have no other graphics issues, so I'd rule out the card. As far as I can tell, this is a cairo issue. I've had confirmation from a Linux user at the Mozillazine Builds forum. I use Win XP.

Comment 10

[-fullmetaljacket-]

confirming, thought i can't reproduce this on mozillazine but i am seeing this bug on this another forum site: http://msforums.ph/forums/thread/196365.aspx (screenshot is coming...)

[this seems a reoccurrence of bug 363674]

Comment 11

[-fullmetaljacket-]

Attachment: another screenshot

Comment 12

[Peter S.]

I'm still randomly getting them in text boxes (like for web forums, etc.)  One time I got them when using my scroll button to scroll up and down.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a4pre) Gecko/20070415 Minefield/3.0a4pre ID:2007041504 [cairo]

Comment 13

[Sean Smith]

When I had the lines, and turned off the status bar, they immediately disappeared. But, as I began scrolling through the page again, they reappeared, even with the status bar off.

Comment 14

[Eston Bond]

This bug can generally be resolved by changing the way floats are cleared on the page. Most examples online appear to occur when a wrapper div is around floated elements and overflow: auto; is used to wrap them.

As a current workaround, one can use overflow: hidden; or multiple other clearing methods to allow a div to wrap properly and stop this bug from happening. That said, it seems as if the cause of this bug (for me, at least) is when using overflow: auto; to wrap a div.

Comment 15

[Peter S.]

http://marksfriggin.com/news.htm

Go there.  Press "end" to jump to the bottom of the page, and you'll see a ton of random lines.  First noticed it in 20070507 build.  Now running:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a5pre) Gecko/20070508 Minefield/3.0a5pre ID:2007050804 [cairo]

Comment 17

[Ria Klaassen (not reading all bugmail)]

If possible, fill in the guilty bug from now on to prevent people filing doubles.

Comment 18

[mdavila78]

I also have the same problem with the lines.

Comment 20

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Marking as [wanted-1.9] for now, but would consider re-evaluating for blocking given more reliable steps to reproduce.

Comment 21

[Eli Friedman]

Let's reevaluate this after the patch for bug 343430 goes in.

Comment 23

[Ria Klaassen (not reading all bugmail)]

Steps to reproduce for the lines that are caused by bug 371187 are:

- Go to http://www.fan.tv/forum/forum_posts.asp?TID=17199
- On the right side you'll see video thumbnails
- With the scrollbar scroll down and up again

Result: lines either through the pictures or through the background of the pictures. The slower you scroll up, the more lines. This is inconsistent with the summary of this bug and given the fact that I can't reproduce the other testcases, changing the summary accordingly, if you agree. 

Comment 24

[Jonathan Haas]

bug 382458 testcase2 (attachment 266728 [details]) shows a very similar problem when scrolling.

Comment 25

[mdavila78]

I also used to have this problem, but I could solve it by upgrading to Firefox 2.0.0.4.

You have to uninstall your previous Firefox then you should install the new version (2.0.0.4).

While using Firefox (2.0.0.3) the "Check for Updates" option under the "Help" menu, didn't show any available updates, so I had to manually download the new Firefox from mozilla.com

Comment 26

[Ryan VanderMeulen [:RyanVM]]

This is a bug on the Firefox trunk (Gecko 1.9), not the Gecko 1.8.1 branch that 2.0.0.4 is based on.

Comment 27

[mdavila78]

The bug appeared again, I have lines black lines crossing my screen.  Even that I have Firefox 2.0.0.4.

I entered this page:

http://www.geocentral.net/geometria/

A Java icon in the windows bar showed,  and now I have these terrible lines again,  maybe Firefox has some kind of problem with Java. 

Comment 28

[Eli Friedman]

(In reply to comment #27)
> The bug appeared again, I have lines black lines crossing my screen.  Even that
> I have Firefox 2.0.0.4.
> 
> I entered this page:
> 
> http://www.geocentral.net/geometria/
> 
> A Java icon in the windows bar showed,  and now I have these terrible lines
> again,  maybe Firefox has some kind of problem with Java. 
> 

If you're having issues with FF 2.0, it's not this bug.  If you're having issues with Java, it's not this bug.  Please file another bug explaining the steps you took to reproduce your bug, preferably with a screenshot.

Comment 29

[Jon Henry]

Attachment: Screenshot from Google Reader

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a6pre) Gecko/20070605 Minefield/3.0a6pre

I can reproduce this nearly 100% of the time on any given Google Reader feed. Attaching a screenshot, note the blue lines in the lower right.

Steps to reproduce:

1. Load Google Reader
2. Browse any feed with a lot of posts (Slashdot, BBC, Planet Mozilla, etc)
3. Scroll down (1-2 times per second) using the mouse wheel or down arrow key.

Possibly significant is that I do not see this when scrolling up, or when dragging the slider box in the scrollbar.

Comment 31

[Ale Mand]

Confirmed in Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9a6pre) Gecko/20070615 Minefield/3.0a6pre

Comment 32

[Heinz Aufner]

Not sure if this will help, but I am seeing this in Hotmail (Windows Live version), but it only happens when in 'Full message view'. You don't see it when you have folder contents displayed.

Comment 33

[Eli Friedman]

Please include the build identifier from "about:" when reporting symptoms of bugs.

Comment 34

[Heinz Aufner]

Re: Comment #32.

Build ID is:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.4) Gecko/20070515 Firefox/2.0.0.4

Comment 35

[Jon Henry]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a7pre) Gecko/2007070509 Minefield/3.0a7pre

After updating to today's build, I am no longer able to reproduce this bug on Google Reader.

Comment 36

[Knud Larsen]

Mozilla/5.0 (Windows; U; Windows NT 6.0; da; rv:1.8.1.4) Gecko/20070515 Firefox/2.0.0.4

Got white lines with Hotmail Live Mail Full version (not with classic version and not in IE)too. When scrolling down. Scrolling up and right clicking lines disappear. No lines with folder contents displayed. Most links describing the the problem I've found involve Firefox (newest and earlier) and Windows Live Mail Full version.

Comment 37

[Eli Friedman]

(In reply to comment #36)
> Got white lines with Hotmail Live Mail Full version (not with classic version
> and not in IE)too. When scrolling down.

It would be useful to know whether this is still an issue on trunk (ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk)

Comment 38

[Knud Larsen]

Attachment: Screenshot from Windows Live Mail

Comment 39

[j.j.]

Can anyone reproduce this bug on latest trunk (Firefox3)?
If not, ->WFM based on comment 35 ?

Comment 40

[Ria Klaassen (not reading all bugmail)]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a7pre) Gecko/2007072121 Minefield/3.0a7pre
Not fixed yet.

Comment 41

[Eli Friedman]

(In reply to comment #40)
> Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a7pre) Gecko/2007072121
> Minefield/3.0a7pre
> Not fixed yet.


Care to elaborate?  (What site is it broken on?)

Comment 42

[Ria Klaassen (not reading all bugmail)]

Attachment: screenshot

Still the same case from comment 23: 
Go to http://www.fan.tv/forum/forum_posts.asp?TID=17199 and scroll down (with the bar or with your mouse). You'll see black lines on the background of the right hand column.

Comment 43

[Ria Klaassen (not reading all bugmail)]

Attachment: screenshot

And the next screenshot is on the same page when you scroll up; now you'll see white lines through the thumbnail images on the foreground.

Comment 44

[Eli Friedman]

I'll look into it. (I hate incremental reflow bugs...)

Comment 45

[j.j.]

(In reply to comment #42) 
> Go to http://www.fan.tv/forum/forum_posts.asp?TID=17199 and scroll down (with
> the bar or with your mouse). You'll see black lines on the background of the
> right hand column.

I can reproduce this as long as the page isn't in the cache.
After reloading the page, it's ok.
The lines come back after clearing the cache.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a7pre) Gecko/2007072005 Minefield/3.0a7pre

Comment 46

[j.j.]

I tryed to reduce Ria's testcase, but I gave up. Smallest random changes let the bug disappear.
http://www.fan.tv/forum/forum_posts.asp?TID=17199

What I found was:
1. The back (scrolling down) and white (scrolling up) stripes are 
   only on the <iframe> of the page.
2. The bug remains if you set <iframe src="about:blank">
3. The "black" stripes are actually in body's background color.
   The page body uses gray background-color and a 
   white background-image ~1000 x 3px.
   Setting body{background-color:red} results in red stipes instead of "black".

The key is probably the 3px height of white background-image in combination with darkgray background-color behind the iframe.

j.j.

Comment 47

[j.j.]

(In reply to comment #46)
> 1. The back (scrolling down) ... 
1. The *black* (scrolling down) ...
...
4. The bug doesn't appear locally. The bug doesn't appear if the page is 
   cached. (clear cache, restart browser to reproduce)

j.j.

Comment 48

[Knud Larsen]

Mozilla/5.0 (Windows; U; Windows NT 6.0; da; rv:1.8.1.5) Gecko/20070713 Firefox/2.0.0.5 (Windows Vista)
After updating to above, I still get horizontal, white lines in Windows Live Mail Full Version, full messages. And still not in classic version, full messages. So with two identical messages, I get lines in the first, but not the latter. The source code headlines are not identical however: Full version: <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN" "http://www.w3.org/TR/html4/frameset.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"> 
Classic version: <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" > <html dir="ltr">

Comment 49

[Eli Friedman]

(In reply to comment #48)
> Mozilla/5.0 (Windows; U; Windows NT 6.0; da; rv:1.8.1.5) Gecko/20070713
> Firefox/2.0.0.5 (Windows Vista)
> After updating to above, I still get horizontal, white lines in Windows Live
> Mail Full Version, full messages. And still not in classic version, full
> messages. So with two identical messages, I get lines in the first, but not the
> latter. The source code headlines are not identical however: Full version:
> <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN"
> "http://www.w3.org/TR/html4/frameset.dtd">
> <html xmlns="http://www.w3.org/1999/xhtml"> 
> Classic version: <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"
> > <html dir="ltr">

At this point none of the developers really care what it looks like in 2.0.*; we don't take fixes for non-critical bugs on branches.

Comment 50

[Ria Klaassen (not reading all bugmail)]

(In reply to comment #47)
Yeah, the site was tested with the default settings of a new profile.
The lines may not occur if you set a minimum font-size larger than 11 in this case.

Comment 51

[Eli Friedman]

Attachment: Testcase

Minimized testcase.  Yes, this is a little weird, but it really can't be minimized any more.

Comment 52

[Eli Friedman]

Attachment: Patch

Making background images work right is really a pain... this patch also contains some cleanups.

Comment 53

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Comment on attachment 273657 [details] [diff] [review]
Patch

This looks fine, but this basically means that if we ever get into this code with a non-integer translation, we're going to be a in a world of performance hurt.  So I hope that layout gets things right...

Comment 54

[Steve Chapel]

Scrolling the page http://www.codedread.com/svg-support.php reliably reproduces the lines for me in the latest nightly build of Firefox.

Comment 55

[Eli Friedman]

The page at http://www.codedread.com/svg-support.php still shows lines for me too... could someone see if it can be reduced somehow to not use SVG?

Comment 56

[Eli Friedman]

Comment on attachment 273657 [details] [diff] [review]
Patch

Checked this patch in.

Comment 57

[Steve Chapel]

Attachment: reduced testcase of CodeDread page (SVG)

I've reduced the CodeDread page to a simplified testcase. It still contains SVG, and in fact, it's in an SVG graphic where the lines are occurring after scrolling.

Comment 58

[Steve Chapel]

I also still get lines in the three small "enlarge" images when I scroll on this page: <http://www.mini-box.com/Mini-Box-M300?sc=8&category=12>. Using smooth scrolling makes the lines more noticeable. These images are JPEGs.

Comment 59

[j.j.]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a7pre) Gecko/2007080204 Minefield/3.0a7pre

Comment 58 confirmed. White lines if I scroll fast.

Comment 60

[Eli Friedman]

The remaining issue seems to be SVG-specific... I'm having trouble figuring out what it is, though.

Comment 61

[tor]

What configuration do you have that shows lines on SVG?  I can't reproduce it here.

Comment 62

[Steve Chapel]

The SVG reduced testcase (comment 57) and JPEG images (comment 58) both display lines on Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a9pre) Gecko/2007100304 Minefield/3.0a9pre. It's worse with smooth scrolling turned on.

Also, on the Bugzilla Change Votes page I get lines in the checkboxes both with and without smooth scrolling on.

I'm not sure if this is three different bugs, or one bug that can affect SVG images, JPEG images, and form widgets.

Comment 63

[dickvl]

I've reduced the SVG (https://bugzilla.mozilla.org/show_bug.cgi?id=376124#c57) to:

data:text/html,%3Cobject%20id%3D'masthead'%20type%3D'image%2Fsvg%2Bxml'%20data%3D'https://bugzilla.mozilla.org/attachment.cgi?id=274159'%20width%3D'500'%20height%3D'100'%3E%3C%2Fobject%3E

I see the white lines if I first scroll down and then up to go back: the white lines appear at the top.
With smooth scrolling off I see a few lines, but with smooth scrolling on the images only consist of white lines.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en; rv:1.9a9pre) Gecko/2007101005 Minefield/3.0a9pre

Comment 64

[dickvl]

Sorry for the wide page in my previous post.

data:text/html,<object id='masthead' type='image/svg+xml' data='https://bugzilla.mozilla.org/attachment.cgi?id=274159' width='500' height='100'></object>

Comment 65

[Steve Chapel]

(In reply to comment #20)
> Marking as [wanted-1.9] for now, but would consider re-evaluating for blocking
> given more reliable steps to reproduce.

Re-nominating for blocking 1.9 now that there are reliable steps to reproduce.

Comment 66

[Cheng Khoon]

Could this be related to Bug 404502?

Comment 67

[Ria Klaassen (not reading all bugmail)]

(In reply to comment #64)
> Sorry for the wide page in my previous post.
> 
> data:text/html,<object id='masthead' type='image/svg+xml'
> data='https://bugzilla.mozilla.org/attachment.cgi?id=274159' width='500'
> height='100'></object>
> 
This specific case was caused by bug 177805.

Comment 68

[Damon Sicore (:damons)]

+'ing, P2, and assigning to vlad as he thinks this may be a dupe.  

Comment 69

[Markus Elfring]

I have got unexpected horizontal lines during vertical scrolling on the following pages.
http://websvn.kde.org/trunk/KDE/kdegames/lskat/src/scoresprite.cpp?revision=731909&view=markup
http://websvn.kde.org/trunk/KDE/kdegames/lskat/src/thememanager.cpp?revision=752469&view=markup

I have also seen it on a discussion display.
http://www.kessels.com/forum/index.php?topic=886.0

The following programs are affected on my system.
Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.1.11) Gecko/2007112718 Firefox/2.0.0.11
Mozilla/5.0 (Windows; U; Windows NT 5.1; de-AT; rv:1.8.1.11) Gecko/20071128 SeaMonkey/1.1.7

Comment 70

[Markus Elfring]

Attachment: Display after a few clicks on the down button of the scroll bar

Comment 71

[Markus Elfring]

Attachment: Display after a slow movement in the up direction with the slider of the scroll bar

Does there exist an open issue with the drawing of horizontal rulers (hr tag) during scrolling?

Comment 72

[Markus Elfring]

Attachment: Display after movement around a horizontal rule in the up direction with the slider of the scroll bar

Comment 73

[j.j.]

Markus, your comments are unrelated here.
This bug is about Gecko 1.9 trunk. Test with Firefox 3.0 beta.

Comment 74

[hhh]

I haven't seen this in either Windows or Linux in 3 weeks. Is anyone still seeing this behavior?

Comment 75

[Steve Chapel]

I can still reproduce the problems from comment #57 and comment #58 with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b3pre) Gecko/2008013104 Minefield/3.0b3pre

Comment 76

[hhh]

Attachment: screenshot

Confirmed with autoscrolling re: comment 58.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b3pre) Gecko/2008013117 Minefield/3.0b3pre

Comment 77

[Jonathan Watt [:jwatt]]

Attachment: much simpler testcase

This small testcase has some comments inline about the type of markup that causes this issue. In addition, note the bug somehow seems related to nsSubDocumentFrame::mRect.y having sub-pixel positioning (having a .5 result when divided by 60.0f).

Comment 78

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Attachment: use NSToCoordRound, not NSToIntRound

A++ testcase would debug again.

Old-world gfx used NSToCoordRound, which was (int) floor(value + 0.5).
We were using NSToIntround, which is lroundf(value) -- which will always round away from 0.  The testcases here all involve negative numbers, so we end up with different rounding directions.  NSToCoordRound is correct (we need the same rounding direction for both positive and negative numbers).

So here we change FROM_TWIPS_INT to use NSToCoordRound, and make sure that the twips-rect-to-gfx-rect function uses FROM_TWIPS_INT instead of FROM_TWIPS (which would keep it as float values).

Note that I tried also changing FROM_TWIPS to round, with the assumption that old gfx was doing that type of rounding always, but that broke stuff -- I saw repainting artifacts when typing in the location bar, and didn't look beyond that.  It feels that we have all sorts of rounding problems, though, and that we're just plugging one symptom after another :(

Comment 79

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

Compositor will help a bit, because we won't have child widgets which are nominally positioned at appunit coordinates but in practice can only be positioned at device pixel boundaries.

Comment 80

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

So this patch caused a reftest failure for me on 368504-5.html at http://mxr.mozilla.org/firefox/source/layout/reftests/bugs/368504-5.html?force=1, with the 5% and 95% cases.  Argh.

Comment 81

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

... and on

!	layout/reftests/pixel-rounding/background-color-top-height-4.html
!	layout/reftests/pixel-rounding/background-color-left-width-4.html
!	layout/reftests/pixel-rounding/background-color-height-top-4.html
!	layout/reftests/pixel-rounding/background-color-width-left-4.html

and some related friends.

Looking at top-height-4, it has:

div { position: absolute; top: 9.5px; left: 10px; height: 10px; width: 10px; }
<div style="height:10.9px"></div>

and it's comparing it to a 10x10 div at 10,10.  The top left corner is in the right spot, but it's 1px bigger, so we're getting a height of 11.  From my reading of the test, this is correct, right?  9.5 will round to 10, the height will round to 11.

(Webkit renders a 10x10 square at 10,9, so my guess is that they're just chopping off coordinates.)

Comment 82

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

(Though looking at those numbers again, lroundf() should also have been giving us 10 and 11.. argh.  Will get some traces tomorrow.)

Comment 83

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

As dbaron pointed out, the test puts the top at 9.5 and the bottom at 9.5+10.9=20.4.  I think that this code is actually totally wrong; we need to be using the gfxRect Round() function, not just rounding x/y/w/h!

I'll fix this and get rid of the macros.

Comment 84

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

Yeah, sorry I should have caught that. Rounding widths and heights is usually wrong.

Comment 85

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Attachment: updated patch

Here's an updated patch.  With this, there is only one reftest failure, at bugs/130767-1.html .  This test is doing:

<body style="padding: 2%">
<div style="background-color: blue; height: 3em">&nbsp;</div>

the change is that now we draw the div one pixel narrower on the right.  This sounds like a valid change to me, as the previous test result was probably incorrect due to the invalid rounding (since this test will be directly affected by my patch).  Does that sound right?

Comment 86

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

No, looking at the tests the results should be identical. There's something bad going on. I'll look into it.

Comment 87

[Jonathan Watt [:jwatt]]

Moving tracking1.9+ back to blocking1.9+ and setting P1 since any changes that mess with units probably should get extra testing in a beta.

Comment 88

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

Strange, so the frames are the same size and position:

              Block(div)(1)@0x244d70c next=0x244d7dc {1219,1219,57562,2880} [state=00100010] sc=0x244d550(i=1,b=0)<

              TableOuter(table)(1)@0x243f8d4 next=0x24424cc {1219,1219,57562,2880} [state=00010010] [content=0x3d0b9b00] [sc=0x243f828] pst=:-moz-table-outer<
                Table(table)(1)@0x243f91c {0,0,57562,2880} [state=00010010] [content=0x3d0b9b00] [sc=0x243f550]<

Comment 89

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

But didn't bug 417967 fix the underlying bug here?

Comment 90

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

OK, so the problem is that nsTablePainter applies a Translate before painting at x=0. The block does not translate so it paints at x=1699. The width is 57562, which is not an integer number of pixels. There is no guarantee that rounding the edges of a rectangle with non-integer width will give the same width at different x-offsets.

So the question is, WHY are we doing this rendering in nsThebesRenderingContext at all? Shouldn't we be relying on gfxContext pixel-snapping?

Comment 91

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

Basically, the way nsThebesRenderingContext is set up now is guaranteed to return different results for Translate(x,y); FillRect(0,0,w,h) vs FillRect(x,y,w,h). That is bad. The rounding needs to depend on the current translation, so rounding in gfxContext is the right thing to do.

Comment 92

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

Passing this hot potato back to Vlad! This latter issue is definitely a gfx issue. Hopefully the actual bug here is fixed though. Too bad my Windows build takes aeons.

Comment 93

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

This looks fixed to me. Can anyone confirm?

Comment 94

[Jonathan Watt [:jwatt]]

Yeah, I'm not seeing the bug any more on WinXP.

Do we still want to take anything from vlad's patch or your suggestions?

Comment 95

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

Let's close this. The problem with the Thebes context rounding in comment #91 is definitely a problem but if we don't need to fix it for 1.9, breat.

Comment 96

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

I agree with roc -- this is a pretty fragile house of cards at the moment, and I'd rather not cause unnecessary problems.  We should definitely look into this for post-1.9 though, and clean all the rounding/pixel snapping/etc. up.

Comment 97

[Steve Chapel]

v

Comment 98

[(not currently active) Ted Mielczarek]

Attachment: oh, the white lines

So, I'm still seeing this occasionally in current nightlies. This screenshot is from Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9pre) Gecko/2008041005 Minefield/3.0pre. I can't reliably reproduce right now, but when it starts happening I can reproduce it repeatedly on the same page. It looks like I was zoomed out there (as I usually am on tinderbox).

Comment 99

[Martijn Wargers (dead)]

The issue that Ted mentioned in comment 98 is now bug 428446.

Comment 101

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

The problem in comment #90 should have been fixed by bug 421069, so Vlad's patch probably should work now.

Comment 102

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

Comment on attachment 306323 [details] [diff] [review]
updated patch

So this looks good, although it's unclear we'd actually still want it.