Closed Bug 456219 Opened 16 years ago Closed 15 years ago

wrong clipping when -moz-background-clip:padding is in effect and box has round corners

Categories

(Core :: Layout: Block and Inline, defect, P3)

defect

Tracking

()

RESOLVED FIXED
mozilla1.9.2a1

People

(Reporter: zwol, Assigned: zwol)

References

Details

(Keywords: fixed1.9.1)

Attachments

(7 files, 13 obsolete files)

1.76 KB, text/html
Details
1.73 KB, text/html
Details
1.71 KB, text/html
Details
674 bytes, text/html; charset=UTF-8
Details
40.04 KB, image/png
Details
58.05 KB, patch
Details | Diff | Splinter Review
53.94 KB, patch
Details | Diff | Splinter Review
Attached file test case
When -moz-background-clip:padding is applied to a box with rounded corners, we clip the background using a rounded rectangle that's shrunk to the size of the padding-box but has the corner radii appropriate for the *outside* of the border-box.  This causes visible gaps between the border and the background; they are especially obvious when the inside of the border-box does not have rounded corners at all, or when the border is not of uniform thickness all the way around.  I will attach a test case and reference.

Note that the test case relies on CSS features not present in FF3.0.

The fix should be straightforward - loosely, we need to apply the existing ComputeInnerRadii function when calculating the clipping path.  I intend to write a patch on Monday.
Attached file reference rendering
> Note that the test case relies on CSS features not present in FF3.0.

I take that back, the test case works (and demonstrates the bug) in 3.0 just fine.  It must have been an earlier iteration that didn't.
Here's a not-quite fix.  I think it's the correct overall approach, but all nonzero-inner-radius borders still have a single-device-pixel seam between the background and the border -- at the corners only -- where whatever's underneath the box with the rounded corners shows through.  I tried making the inner radii slightly tighter than they should be, but that didn't help.

Asking vlad to review primarily because he might have some idea of what to do about the seams.
Attachment #339877 - Flags: review?(vladimir)
That seems fine, but I don't know what to do about the seams -- there really isn't anything we can do with the type of antialiasing that happens currently.  Only thing I can think of would be to expand the clip out by a pixel or so -- is that what you tried?
I didn't try exactly that, but now I have.  It works visually, but the reftests I wrote for it still fail (this may be due to the same problem as bug 456312) and it seems to cause at least a few other tests to fail (the ones for bug 403249).  Also, I can concoct a test that it would break, where you have a semitransparent border color and a background image that's now slightly overlapped with the border.

I don't have a better idea either, though :-/
Attachment #339877 - Attachment is obsolete: true
Attachment #339877 - Flags: review?(vladimir)
This is the test case I said I could concoct in the previous message.  Load it up in a browser with patch rev 1 applied and you'll see a green smudge at every rounded corner.  Depending on zoom level I also see hairlines of white on some of the boxes.
(In reply to comment #5)
> Created an attachment (id=339919) [details]
> (rev 1) visually correct, own reftests fail + breaks others
> 
> I didn't try exactly that, but now I have.  It works visually, but the reftests
> I wrote for it still fail (this may be due to the same problem as bug 456312)
> and it seems to cause at least a few other tests to fail (the ones for bug
> 403249).  Also, I can concoct a test that it would break, where you have a
> semitransparent border color and a background image that's now slightly
> overlapped with the border.
> 
> I don't have a better idea either, though :-/

Yeah, this is what we currently do for rounded backgrounds -- see http://hg.mozilla.org/mozilla-central/file/31f1081d9681/layout/base/nsCSSRendering.cpp#l2412 .  I don't think there's a better solution unless/until we can do some supersampling :(
So this revision includes code functionally equivalent to what you quoted - one actually has to *subtract* from the inner corner radius to get it to do the right thing, but other than that it is so.  And one device pixel isn't enough.  This patch uses two, which is still not enough to get the reftests to pass, but I am leery of increasing it further without some sort of backstop against going outside the border-box.  (Also, the larger this number is, the worse the fringing will be when the border color is translucent.)

I am tempted to recommend that we check this in either as is or without any adjustment to the inner corner radius, mark the reftests todo (which is done here) and file another bug for ultimately getting it right.  I'd like to get back to actual elliptical corners before the code freeze...
Attachment #339919 - Attachment is obsolete: true
Attachment #340066 - Flags: superreview?(dbaron)
Attachment #340066 - Flags: review?(vladimir)
New approach - clip to the tightest regular rectangle we can manage, but if rounded corners are in effect, also clip to the rounded rectangle that's the *outer* boundary of the border, no matter what the background-clip is.  This eliminates the seams but has the downside of drawing 'underneath' a rounded border whose inner curves encroach on the padding-box.  This will be unnoticeable unless the border is at least partially transparent so I think it's an acceptable tradeoff given that we *can't* get this right without more help from cairo.

Unfortunately the patch, as is, breaks all display in horrible ways and I can't figure out why.  Content other than backgrounds are not drawn, or disappear and reappear if moused-over, the window loses focus, ...
Attachment #340066 - Attachment is obsolete: true
Attachment #340066 - Flags: superreview?(dbaron)
Attachment #340066 - Flags: review?(vladimir)
This revision is simpler and less invasive, doesn't have the catastrophic rendering errors that rev 2 did, doesn't break any reftests, and produces visually correct renderings in all cases but one.  However, its own reftests all fail, with (no longer human-visible) fringes of erroneous pixels at both the inner and outer boundaries of rounded border corners.  I am officially stumped as to how to make these failures go away.  You'll note that the old kludge that increased the radius used for backgrounds by one device pixel is gone; that's because in my tests it made no difference whatsoever.

Not covered in the reftests in this patch is the rendering case that is *seriously* wrong even with this patch: if you set -moz-background-clip:padding, a solid semitransparent (alpha < 1) border, and border radii greater than the border width, the background corners will be drawn into the border area.  This is unfixable without help from cairo.
Attachment #341005 - Attachment is obsolete: true
Attachment #341028 - Flags: review?(roc)
(In reply to comment #10)
> Not covered in the reftests in this patch is the rendering case that is
> *seriously* wrong even with this patch: if you set
> -moz-background-clip:padding, a solid semitransparent (alpha < 1) border, and
> border radii greater than the border width, the background corners will be
> drawn into the border area.  This is unfixable without help from cairo.

What kind of help?  I'm not really sure what the above is referring to (I'm not too familiar with backgronud-clip) -- can you describe the actual rendering that should happen?
> What kind of help [from cairo]?

I was referring to the supersampling you mentioned in comment 7.  Until we have that there's no point even trying to clip to the inner radii of the border corners, because of the seaming effect.  So instead, in the problem case, the patch has us clipping to the outer rounded rectangle and then again to the padding-box without rounded corners; which means that if the border is semitransparent, you'll see the background drawn underneath the border at the corners.

Of course I've still got tons of single-pixel errors even in more normal cases; my frustration level is approaching "screw this bug anyway"...
Ah, ok; supersampling most likely won't be done by cairo directly but using cairo (I mean, we can already do it -- just need to render everything at 2x size with AA turned off, and then scale down at the end... but lots of things, like text, break with that simplistic approach.).

But, I wouldn't say 'screw this bug anyway' -- single pixel errors of a few colors are perfectly fine, if things visually look correct.  Our reftests don't have a way to say "this isn't ideal, but if it's within N pixel values it's ok", which makes testing harder, though.
No longer blocks: 450652
Blocks: 450652
No longer blocks: 450652
(In reply to comment #0)
> When -moz-background-clip:padding is applied to a box with rounded corners, we
> clip the background using a rounded rectangle that's shrunk to the size of the
> padding-box but has the corner radii appropriate for the *outside* of the
> border-box.  This causes visible gaps between the border and the background;
> they are especially obvious when the inside of the border-box does not have
> rounded corners at all, or when the border is not of uniform thickness all the
> way around.  I will attach a test case and reference.

This actually wasn't true before the patch to bug 450652, at least for background color.  At the very least, we should unregress what that patch broke.

I'd also say that it's worth remembering that in the bulk of cases, many of these features aren't going to be used at the same time, so I think you're better off avoiding the 1px-extra code and living with the slight seams, at least for now.  I'd rather get things right in the simple case and wrong in the complex case than the other way around.  After all, we have those seams in many other cases (e.g., a border on one element and a background on something inside it with a radius computed to match) that should, in theory, work; it seems odd to fix them in just one of the many cases.
Blocks: 450652
Flags: blocking1.9.1?
Also, it looks like this patch was bitrotted by what actually landed for bug 450652, since PaintRoundedBackground no longer exists on the trunk.  (I've been noticing these changes as I keep bug 322475 merged to trunk.)
Yet another revision.  This applies cleanly to latest trunk, and goes back to using exactly the clipping area that we ideally ought to.  Thus, there are visible fringes in attachment 339601 [details] but not in attachment 339920 [details].  In dbaron's test case (attachment 341949 [details]) both regions filled with aqua are the same shape, but there are visible aqua fringes at the *outside* of the border area for the first case only.  However, I can see similar (slightly fainter) fringes in a 3.0 build, so maybe we can live with that.
Attachment #341028 - Attachment is obsolete: true
Attachment #342005 - Flags: review?(roc)
Attachment #341028 - Flags: review?(roc)
Comment on attachment 342005 [details] [diff] [review]
(rev 4) going back to the with-seams version; fixes regression (sort of)

Isn't it possible to write some test that passes here? You can censor the seams by placing boxes over those areas in both the test and reference.
Attachment #342005 - Flags: superreview+
Attachment #342005 - Flags: review?(roc)
Attachment #342005 - Flags: review+
We should get this patch checked in even if we can't figure out how to write a good test for it.
Keywords: checkin-needed
I doubt the patch above is anywhere remotely close to applying after bug 458487 landed.
It won't be hard to fix up when I get a chance.
Attachment #342005 - Flags: approval1.9.1b2?
Keywords: checkin-needed
Flags: blocking1.9.1? → blocking1.9.1+
Priority: -- → P3
This revision updates the patch to apply to latest trunk (in particular, on top of roc's pixel snapping changes) and adds mask images to three of four test cases so that they pass despite the seams that we still get between background and border.  If this general approach seems good to people, I'll file a new bug for the seams and adjust the comments in the tests to match.

The fourth test, which still doesn't quite work, is based on dbaron's attachment 341949 [details].  I think the remaining difference between test and reference is the same seaming problem, rather than an actual change in border radius, and it could be masked out the same way if we consider the actual regression to be dealt with, but I wanted to run that by folks first.
Attachment #342005 - Attachment is obsolete: true
Attachment #348303 - Flags: review?(roc)
Attachment #342005 - Flags: approval1.9.1b2?
+  // If we have rounded corners and no caller-provided clip rectangle,
+  // clip to the rounded rectangle forming the outer or inner boundary
+  // of the border, as computed above.
+  gfxContextAutoSaveRestore autoSR(ctx);
+  if (haveRoundedCorners && !aBGClipRect) {

Shouldn't we intersect aBGClipRect with the rounded-corners path?

It would be more efficient to fill a rounded-rect than clip to the rounded-rect and fill a normal rect. I don't know if that should matter here.
(In reply to comment #25)
> +  // If we have rounded corners and no caller-provided clip rectangle,
> +  // clip to the rounded rectangle forming the outer or inner boundary
> +  // of the border, as computed above.
> +  gfxContextAutoSaveRestore autoSR(ctx);
> +  if (haveRoundedCorners && !aBGClipRect) {
> 
> Shouldn't we intersect aBGClipRect with the rounded-corners path?

Two problems there - first, I'm not sure that's the right thing to do when we have a caller-provided clip rect; second, Cairo doesn't seem to have a general path intersection primitive.

> It would be more efficient to fill a rounded-rect than clip to the rounded-rect
> and fill a normal rect. I don't know if that should matter here.

Probably does; I shall see if it's practical to turn it around (clip to the dirtyRect).
(In reply to comment #26)
> (In reply to comment #25)
> > +  // If we have rounded corners and no caller-provided clip rectangle,
> > +  // clip to the rounded rectangle forming the outer or inner boundary
> > +  // of the border, as computed above.
> > +  gfxContextAutoSaveRestore autoSR(ctx);
> > +  if (haveRoundedCorners && !aBGClipRect) {
> > 
> > Shouldn't we intersect aBGClipRect with the rounded-corners path?
> 
> Two problems there - first, I'm not sure that's the right thing to do when we
> have a caller-provided clip rect; second, Cairo doesn't seem to have a general
> path intersection primitive.

It is the right thing to do IMHO. The caller doesn't want anything drawn outside aBGClipRect, so we'd better restrict to that rect. And of course we should restrict to the rounded-rect as well. The only caller I know about that uses aBgClipRect is tables, where we paint the backgrounds of the row, row-group and table behind each cell. I'm not sure how tables are supposed to behave with rounded corners but surely we don't want to ignore aBGClipRect just because there's a 0.1px border-radius, say.

You don't need a path intersection primitive here. Just clip twice, first to aBGClipRect then to the rounded rect (or the other way around if that's more convenient).
Whiteboard: [needs re-review on revised patch]
Whiteboard: [needs re-review on revised patch] → [needs revised patch and re-review]
I was worried that users of the aBGClipRect argument might pass a rectangle that's *not* entirely within the computed background area, and I seem to have been right; restricting to the intersection of aBGClipRect and the computed background area appears to regress reftests 403249-1[ab] -- the green background is a little smaller than it's supposed to be.
Also, I should mention that when we have both aBGClipRect and rounded borders, it's the rounded borders that get ignored for background-painting purposes.
(In reply to comment #29)
> Also, I should mention that when we have both aBGClipRect and rounded borders,
> it's the rounded borders that get ignored for background-painting purposes.

See also bug 455668 relating to that combination.
OK, just ignore rounded borders when aBGClipRect is present, then.
(In reply to comment #31)
> OK, just ignore rounded borders when aBGClipRect is present, then.

That's what the existing patch does.
Oh, right. Then I guess this patch is good, modulo these comments:

+   judged acceptable for Gecko 1.9.1.  If you fix bug #nnnnnn,

Better fix "nnnnnn"

I don't think it's worth creating a "456219" subdirectory. You can just put everything in the "bugs" directory.
(In reply to comment #33)
> Oh, right. Then I guess this patch is good, modulo these comments:
> 
> +   judged acceptable for Gecko 1.9.1.  If you fix bug #nnnnnn,
> Better fix "nnnnnn"

Right.  I was just holding off on filing that bug until we were all happy with what's been done in this bug.

> I don't think it's worth creating a "456219" subdirectory. You can just put
> everything in the "bugs" directory.

Ok.

What should I do about the fourth test that still fails (based on dbaron's case)?  Drop, or add another mask image, or...
Add another mask image I think.
N.B. this depends on 459148, because the mask images break if the ellipse drawing parameters change, so we need to nail that one down first.
Depends on: 459148
No longer depends on: 459148
Here's the patch with all the requested revisions to the test cases.  The seaming is now bug 466572.
Attachment #348303 - Attachment is obsolete: true
Attachment #349872 - Flags: superreview?(roc)
Attachment #349872 - Flags: review?(roc)
Attachment #349872 - Flags: approval1.9.1?
Attachment #348303 - Flags: review?(roc)
Comment on attachment 349872 [details] [diff] [review]
(rev 6) all tests pass, bug numbers filled in

guess this doesn't really need another review pass.
Attachment #349872 - Flags: superreview?(roc)
Attachment #349872 - Flags: superreview+
Attachment #349872 - Flags: review?(roc)
Attachment #349872 - Flags: review+
Whiteboard: [needs revised patch and re-review]
I want to re-emphasize that this must not land before bug 459148, because the mask images were developed with that patch in place, so the tests will fail if this lands first.
Depends on: 459148
Comment on attachment 349872 [details] [diff] [review]
(rev 6) all tests pass, bug numbers filled in

+  gfxRect gDirtyRect(RectToGfxRect(dirtyRect, appUnitsPerPixel));
+    gfxRect gBgArea(RectToGfxRect(bgArea, appUnitsPerPixel));

Don't use "g" here, it's not global.

+  // Make that rectangle the clipping area for all subsequent drawing.
+  gfxContextAutoSaveRestore autoSR(ctx);
+  ctx->Clip(gDirtyRect);
+

Do we need to do this? It would be much better if we don't.

You're intersecting *aBgClipRect with the frame's bgClipArea. Didn't we decide you should keep on replacing bgClipArea with *aBgClipRect, as the current code does?
We need a new patch here.
Whiteboard: [needs landing]
Here's an updated patch which applies to latest trunk and addresses most of roc's comments.  The remaining issue is the unconditional clipping; eliminating it should be doable but will be complicated.  I'll see if I can't get it done tomorrow.
Whiteboard: [needs revised patch]
This revision does the context save and clip in PaintBackgroundWithSC only for rounded corners (where we have no choice).  If it's a plain rectangle, there's no clipping at all.  Before the patch there was a clip to the dirtyRect for plain rectangles, but I *think* we can rely on nsLayoutUtils::DrawImage not to screw the pooch.
Attachment #349872 - Attachment is obsolete: true
Attachment #352031 - Attachment is obsolete: true
Attachment #353332 - Flags: superreview?(roc)
Attachment #353332 - Flags: review?(roc)
Comment on attachment 353332 [details] [diff] [review]
(rev 8) clips only for rounded corners

+    gfxRect tBgArea(RectToGfxRect(bgArea, appUnitsPerPixel));

I think gfxBgArea or bgAreaGfx would be a better name.

+  gfxRect tDirtyRect(RectToGfxRect(dirtyRect, appUnitsPerPixel));

Similar here.
Attachment #353332 - Flags: superreview?(roc)
Attachment #353332 - Flags: superreview+
Attachment #353332 - Flags: review?(roc)
Attachment #353332 - Flags: review+
Attachment #353332 - Attachment is obsolete: true
Attachment #353336 - Flags: superreview+
Attachment #353336 - Flags: review+
Attachment #353336 - Flags: approval1.9.1?
Keywords: checkin-needed
Whiteboard: [needs revised patch]
Attachment #353336 - Flags: approval1.9.1?
What reftests have you run here?
just what's in layout/reftest/reftest.list; if there are others I don't know about them.
yah.
Just discovered I'd forgotten to 'hg qrefresh' before uploading the previous patch.  Sorry.
Attachment #353336 - Attachment is obsolete: true
Attachment #353552 - Flags: superreview+
Attachment #353552 - Flags: review+
Attachment #353552 - Attachment description: (rev 9a) names *actually* changed as requested → (rev 9a) names *actually* changed as requested [Checkin: Comment 51]
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Whiteboard: [c-n: baking for 1.9.1]
Target Milestone: --- → mozilla1.9.2a1
Status: RESOLVED → REOPENED
Keywords: checkin-needed
Resolution: FIXED → ---
Whiteboard: [c-n: baking for 1.9.1]
Comment on attachment 353552 [details] [diff] [review]
(rev 9a) names *actually* changed as requested
[Backout: Comment 52]

Backed out:
http://hg.mozilla.org/mozilla-central/rev/3bd51dff318a
http://hg.mozilla.org/mozilla-central/rev/0ee09d199a86
See for example:
{
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1229737744.1229743825.20293.gz
MacOSX Darwin 9.2.2 mozilla-central moz2-darwin8-slave01 dep unit test on 2008/12/19 17:49:04

REFTEST TEST-UNEXPECTED-FAIL | file:///builds/slave/trunk_darwin-1/build/layout/reftests/bugs/456219-1a.html | 
REFTEST TEST-UNEXPECTED-FAIL | file:///builds/slave/trunk_darwin-1/build/layout/reftests/bugs/456219-1b.html | 
REFTEST TEST-UNEXPECTED-FAIL | file:///builds/slave/trunk_darwin-1/build/layout/reftests/bugs/456219-1c.html | 
REFTEST TEST-UNEXPECTED-FAIL | file:///builds/slave/trunk_darwin-1/build/layout/reftests/bugs/456219-2.html | 
}

3 MacOSX boxes failed; Linux and Windows passed.
Attachment #353552 - Attachment description: (rev 9a) names *actually* changed as requested [Checkin: Comment 51] → (rev 9a) names *actually* changed as requested [Backout: Comment 52]
MacOS is showing a small number of differences on the inside curves of the borders, which could be corrected for in the mask images.  But it's also showing single-pixel differences on the *outside* curve of the borders.  These cannot  be corrected for in mask images, because the platforms don't agree on what the "correct" color of the problem pixels should be.  In other words, masking all the pixels that fail on MacOS with the reference colors seen on MacOS would break the tests on Linux and Windows.

I recommend we XFAIL these tests on MacOS.  Thoughts?
(In reply to comment #53)
> I recommend we XFAIL these tests on MacOS.  Thoughts?

Sounds fine to me.
I would prefer to ignore just the antialiased pixels on the outside of the borders, either by overlaying a transparent PNG which whites out just the antialiased pixels, or by using an SVG filter (like dbaron did in another bug whose number I forget) to transform pixels with fractional alpha values to something known.
Here's a revision with much more aggressive pixel masking on the test cases, I hope sufficient to allow them to pass on Mac.
Attachment #353552 - Attachment is obsolete: true
Keywords: checkin-needed
Pushed 5041ce453104
Status: REOPENED → RESOLVED
Closed: 16 years ago15 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Whiteboard: [needs landing] → [needs 191 landing]
Backed out --- tests failed again on Mac.

My bad, I should have checked them before I landed. Tomorrow I'll try to see what's up.
Status: RESOLVED → REOPENED
Flags: in-testsuite+
Resolution: FIXED → ---
Whiteboard: [needs 191 landing] → [needs new patch]
I created this image with my image editor.
The 13 white pixels in the green blobs are those that differ between the test and the reference. Adding those to the mask images will probably work.
Thanks, Markus!  Here is a revised patch adding those 13 pixels to the mask images.  Can someone give the revision a spin on a Mac?
Attachment #355723 - Attachment is obsolete: true
Whiteboard: [needs new patch] → [needs testing on Mac]
The tests now pass on my Mac.
Keywords: checkin-needed
Whiteboard: [needs testing on Mac] → [needs landing]
Pushed 17b08b9bae0c
Status: REOPENED → RESOLVED
Closed: 15 years ago15 years ago
Flags: in-testsuite+
Keywords: checkin-needed
Resolution: --- → FIXED
Whiteboard: [needs landing]
I still see approximately a one pixel outline in a number of the shapes for the following testcase https://bugzilla.mozilla.org/attachment.cgi?id=339601 in build:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090108 Minefield/3.2a1pre ID:20090108184749

~B
Which is pretty much what was identified here: https://bugzilla.mozilla.org/attachment.cgi?id=355974

~B
(In reply to comment #63)
> I still see approximately a one pixel outline 

That's bug 466572
Depends on: 472769
I'm probably going to give up on merging this with bug 322475; but since I've been poking at it... it looks like this patch regressed printing white backgrounds for things that have a background-image but not a background-color; there used to be an IsTransparent() check that seems to have been replaced by only an NS_GET_A() check on the color.
In particular, I'm suggesting maybe it should have been:

  } else {
    bgColor = NS_RGB(255, 255, 255);
    if (drawBackgroundImage || !aColor.IsTransparent())
      drawBackgroundColor = PR_TRUE;
  }
Hm, yeah, looks like I assumed IsTransparent() was a hangover from the days of a separate transparency flag rather than having anything to do with background images.  Plz go ahead and change it.

I may look at merging up bug 322475.
bug 322475 isn't necessarily going to land anytime soon, and certainly not for 1.9.1, so we should fix regressions separately from it.

I'll probably finish up the merging at some point; I did part of it, which is in http://hg.mozilla.org/users/dbaron_mozilla.com/patches/file/tip/unapplied.multiple-backgrounds
Yah, what I'm saying is, you can write and check in the one-line patch easier than I can write it and mail it to you to check in. :-/
Whiteboard: [c-n: baking for 1.9.1]
Depends on: 474208
Could this be the cause of bug 475535?
Depends on: 475535
(In reply to comment #72)
> Could this be the cause of bug 475535?
(Yes, this is indeed the cause, as noted in bug 475535 comment 3)
Mats' patch in bug 475535 may well be correct, but as I said in that bug, I don't know how it worked before if that's so.
Blocks: 479992
Blocks: 476738
What's the status of getting this landed on 1.9.1?
I want to get bug 475535 done first (looks like I have a regression from *that* to fix, sigh) and then we can land 'em both on 1.9.1 together.
Whiteboard: [c-n: baking for 1.9.1] → [needs 1.9.1 landing]
(In reply to comment #76)
> and then we can land 'em both on 1.9.1 together.

Could you also land bug 472769 together with those?  It's been baking on mozilla-central for a month and it has approval1.9.1+, but it can't land until this bug here lands, because it's a regression from this bug.
(In reply to comment #77)
> Could you also land bug 472769 together with those?
(or just ping me to remind me to land it (after you've landed this) -- I just want to make sure it gets in before the beta code freeze :))
Is there anything that should land before this? The patch didn't apply cleanly, last I tried.
The patch needed to be merged with bug 455364. (Their landing order was reversed.)
This patch also includes dbaron's fixup from comment 71.
It looks like we need a branch patch in bug 475535 before we can land this.
Whiteboard: [needs 1.9.1 landing] → [needs branch patch in bug 475535] [needs 1.9.1 landing]
http://hg.mozilla.org/releases/mozilla-1.9.1/rev/b410d21c51e3
Keywords: fixed1.9.1
Whiteboard: [needs branch patch in bug 475535] [needs 1.9.1 landing]
In bug 498689 I needed to update the mask images for a new rasterizer. All of the changes are single pixels near the edges. Hopefully, that's sane.
Blocks: 564274
Blocks: 578121
You need to log in before you can comment on or make changes to this bug.