9 years ago
9 years ago


(Reporter: jwatt, Unassigned)


({pp, regression})

Mac OS X
pp, regression
Bug Flags:
wanted1.9.1 +

Firefox Tracking Flags

(Not tracked)




(2 attachments, 1 obsolete attachment)


When you make the window wider and narrower you will see that some gradients get clipped. When you scroll the window up and down slowly you will also see some weird clipping.
Flags: blocking1.9.1+
I'm not seeing any of this on Windows at all.


9 years ago
Keywords: pp
OS: All → Mac OS X


9 years ago
Keywords: regressionwindow-wanted
I'd start looking around 2009-03-20-04 when the latest cairo upgrade landed if I was looking for a regression window.
Has the same problem on 3.0.8 Mac platform:

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv: Gecko/2009032608 Firefox/3.0.8
Is this a regression at all then Jonathan?
Apparently this regressed between Firefox 2.0 and 3.0. It works in Firefox 2.0.20, but is broken in Firefox 3.0.6. I'm surprised nobody on Mac has reported this already, but if it's not a regression from Firefox 3.0 then I guess this isn't a strict blocker. Would be good to get it in though.
Flags: wanted1.9.1+
Let's take it off the blocker list then.

If we can come up with a simple canvas testcase then we can probably convince Vlad it's a cairo/gfx bug...
Flags: blocking1.9.1+
Canvas doesn't support an equivalent of 'extendMethod' and it effectively defaults to 'pad'. Since this bug only appears with the values 'reflect' and 'repeat', we can't reproduce this using canvas.
Created attachment 374426 [details]
testcase - scroll rect in and out of view

This testcase seems somewhat related. Scrolling the blue rectangle in and out of view produces really bad rendering artifacts. Again, it only happens for 'repeat' and 'mirror' gradients.
Created attachment 374428 [details]
testcase - svg only (rects are offset 500px across, 600px down)

When I scroll this testcase in and out of view vertically and I see entire bands of the gradient not being painted. Interestingly, the stroke around the <rect>s that are filled with the gradients is always painted file, even though the gradient contents are not, as is the <line> across the <rect>s.

Horizontal scrolling is always repainted correctly. So if I've paused vertical scrolling at a point where I'm seeing lots of bands, I can horizontally scroll parts of the <rect>s in and out of view, and each part I bring horizontally back into view is then cleaned up.

Interestingly, it's only on Minefield that I see banding happening when strolling both up and down. In Firefox 3.1 beta 3 the banding only occurs when the <rect>s are scrolled into view from the bottom. When scrolled into view from the top, everything paints fine.


9 years ago
Attachment #374428 - Attachment description: testcase - svg only → testcase - svg only (rects are offset 500px across, 600px down)
Created attachment 374429 [details]
testcase - svg only (rects are offset 500px across, 600px down)
Attachment #374428 - Attachment is obsolete: true
Hardcoding nsSVGOuterSVGFrame::mEnableBitmapFallback to true, in other words enabling the PushGroup/PopGroupToSource calls around the nsSVGUtils::PaintFrameWithEffects call in nsSVGOuterSVGFrame::Paint, fixes this bug. I'm not sure exactly why pushing a group would cause a *larger* area to be painted.
Perhaps because it creates a different kind of Quartz surface, perhaps working around a Quartz bug?
Is this still broken?
No, this works now in both trunk and 1.9.2.
Last Resolved: 9 years ago
Resolution: --- → WORKSFORME
Not worth checking for a regression range on an already fixed bug.
Keywords: regressionwindow-wanted
You need to log in before you can comment on or make changes to this bug.