618071 - Incorrect painting in bugzilla change columns

Status: RESOLVED FIXED

(Core :: Graphics, defect)

Description

[Damon Sicore (:damons)]

Attachment: Screenshot

Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b8pre) Gecko/20101206 Firefox/4.0b8pre

Steps to repro:

1) Open any bugzilla search.
2) Choose change columns.
3) Start adding/removing columns.  
4) You will see chunks of the page starting to disappear.  Eventually almost everything disappears, but elements will reappear when you move the mouse over the page where content should be.

See attached screenshot.

Comment 1

[Damon Sicore (:damons)]

I'm marking this blocking beta 8 because it breaks a really simple bugzilla interface and that means it might also break a ton of other sites.

Comment 2

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

Maybe related to Mac GL work.

Does it go away if you disable GL layers?

Comment 3

[Joe Drew (not getting mail)]

I can't reproduce this on tonight's nightly on my Macbook Pro.

Comment 4

[Damon Sicore (:damons)]

Disabling GL doesn't fix the issue.

Comment 5

[Damon Sicore (:damons)]

Aha!  It's zooming.  I'm always in some level of zoom because it's so easy to accidentally zoom.  Then, you are zoomed forever.

Comment 6

[Damon Sicore (:damons)]

Zoom out.  jrmuizel can repro as well.

Comment 7

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

I see this on Linux too (when zoomed out one step), on:

https://bugzilla.mozilla.org/colchange.cgi?bug_status=REOPENED&bug_status=NEW&bug_status=ASSIGNED&bug_status=UNCONFIRMED&field0-0-0=cf_blocking_20&query_format=advanced&type0-0-0=substring&value0-0-0=beta8&query_based_on=
(which is change-columns on the b8 blocker list).

All I need to do to see it is click on a field in the "Available Columns" list.

Comment 8

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

Based on 64-bit Linux nightlies, regression range is:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=baa5ae44f0ba&tochange=0ff6d5984287

(That took me longer than it should have because I started with a profile that wasn't clean, and was set to "Zoom Text Only".)

Comment 9

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

Nothing in that range jumps out at me...

Comment 10

[Joe Drew (not getting mail)]

If I squint very hard and have had a lot to drink I could believe that Bas' border changes are capable of causing this bug.

Does someone care to do an hg bisect? If not I'll do one myself tomorrow.

Comment 11

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

Yeah maybe.

This could be us hitting a cairo error. Setting a breakpoint on _cairo_error is always good times...

Comment 12

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

I started on the bisect (with a few false starts due to having a bad tree, so I'm just getting through the first big rebuild for the middle of that window.

(Why don't we save tinderbox builds more than a day?)

Comment 13

[Joe Drew (not getting mail)]

(In reply to comment #12)
> (Why don't we save tinderbox builds more than a day?)

Bug 617626!

Comment 14

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

Attachment: cairo error stack

Yep, we're hitting a cairo error, and it looks like it's from the border code.

Comment 15

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

(Given that, I'm not going to bother with the rest of the bisect.)

Comment 16

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

num_dashes=-1186559040 looks a bit suspect...

Bas, if you can't fix this right away, we should probably just back out the border-rendering changes for beta8.

Comment 17

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

I think gdb is lying about a lot of the params in the stack, but what's actually happening is that we're in the second SetDash call, and mBorderWidths[0] is zero (which means there's really no border to draw at all).

Comment 18

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

(In reply to comment #17)
> I think gdb is lying about a lot of the params in the stack, but what's
> actually happening is that we're in the second SetDash call, and
> mBorderWidths[0] is zero (which means there's really no border to draw at all).

Yep, I confirmed that that's what's happening via printf.

Comment 19

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

Attachment: patch

Comment 20

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

I landed the patch:
http://hg.mozilla.org/mozilla-central/rev/09ae1392ac05

I also tried writing a test, and landed it, even though it doesn't fail without the patch in the harness (I'm not sure why not):
http://hg.mozilla.org/mozilla-central/rev/7cf0918f3bfa