Closed Bug 618071 Opened 9 years ago Closed 9 years ago
Incorrect painting in bugzilla change columns
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.
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.
blocking2.0: --- → beta8+
Maybe related to Mac GL work. Does it go away if you disable GL layers?
I can't reproduce this on tonight's nightly on my Macbook Pro.
Disabling GL doesn't fix the issue.
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.
Zoom out. jrmuizel can repro as well.
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.
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".)
Nothing in that range jumps out at me...
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.
Yeah maybe. This could be us hitting a cairo error. Setting a breakpoint on _cairo_error is always good times...
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?)
Yep, we're hitting a cairo error, and it looks like it's from the border code.
(Given that, I'm not going to bother with the rest of the bisect.)
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.
Component: Layout → Graphics
QA Contact: layout → thebes
Assignee: nobody → bas.schouten
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 is zero (which means there's really no border to draw at all).
(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 is zero (which means there's really no border to draw at all). Yep, I confirmed that that's what's happening via printf.
Attachment #496732 - Flags: review?(roc) → review+
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
Assignee: bas.schouten → dbaron
Status: NEW → RESOLVED
Closed: 9 years ago
OS: Mac OS X → All
Hardware: x86 → All
Resolution: --- → FIXED
Target Milestone: --- → mozilla2.0b8
You need to log in before you can comment on or make changes to this bug.