[Tracking Requested - why for this release]: This bug is a regression in 41 that does not appear to affect 42. STR: 1. Load http://everytimezone.com/ 2. Click and drag the "your local time" button *rapidly* back and forth. RESULT: In Aurora 41, but not Nightly 42, the blue and gray bars will start streaking. See the attached screenshot. I bisected this regression to this mozilla-inbound pushlog, which points to a backout of bug 1174923. Should that patch have been backed out on Aurora, too? https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=88c6b4df3eb2&tochange=966e5c2db9f6 966e5c2db9f6 Phil Ringnalda — Back out 3a06964c6a52 (bug 1174923) for box-decoration-break-first-letter.html failures
(In reply to Chris Peterson [:cpeterson] from comment #0) > I bisected this regression to this mozilla-inbound pushlog, which points to > a backout of bug 1174923. Should that patch have been backed out on Aurora, > too? Bug 1174923 got landed again the next day, so it is in nightly as well. So if you are not seeing this bug in nightly then maybe it's caused by something else? Maybe double check the regression range?
I definitely do not see this in Nightly 42. I tried bisecting between 40 and today instead of just between 40 and 41. I ended on this mozilla-central pushlog, which does include Seth's bug 1174923: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=2694ff2ace6a&tochange=c319f262ce3e However, when I continued to bisect mozilla-inbound, I ended on this pushlog for SpiderMonkey bug 1173764, which doesn't make any sense: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=5a2ecacde67d&tochange=0aa70076583f Bisection won't be reliable if the regressing changeset landed, was backed out, and landed again later.
Bisection will still work if a regressing changeset was landed, backed out, and landed again. It just has more than one possible end point, but it should find one of the end points. If you don't see this on nightly then something must have fixed it? Can we bisect to find what fixed it? Maybe we just need to uplift something.
I wonder whether this bug is related to GPU switching. I am using a Retina MacBook Pro and a non-HiDPI external display. I can only reproduce this bug if I *open* the page in a window on my MBP's builtin display, regardless of which display I move the window to when I click and drag the "your local time" button. * open page on BUILTIN display + drag button on BUILTIN display = repro * open page on BUILTIN display + drag button on EXTERNAL display = repro * open page on EXTERNAL display + drag button on BUILTIN display = no repro! * open page on EXTERNAL display + drag button on EXTERNAL display = no repro!
@ Matt, do you think your SkiaGL changes fixed this bug or are just masking it? I tried bisecting the point where this regression went away during Nightly 42. I came to this pushlog, which points to SkiaGL bug 1150944: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=da2876c5f5ac&tochange=6444888e596c And indeed, if I flip gfx.canvas.azure.accelerated to false (from default true) in Nightly 42, I can then reproduce this bug. If I set gfx.canvas.azure.backends to "cg" (from default "skia") in Aurora 41, then I can no longer reproduce this bug. So this bug seems to be related to using unaccelerated Skia canvas?
Depends on: 1150944
Flags: needinfo?(seth) → needinfo?(matt.woodrow)
It seems unlikely that the monitors would affect a bug in skia-software, so I'd assume that my change is just hiding something.
I think this is a wontfix for 41, regression non-withstanding.
I bisected this to https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=d1d45ce7cbf5&tochange=eccde665c72a bug 1167235. It looks like it is something to do with retina displays. Based on comment 4 and the fact that the wrongly draw bars look to be drawn at about half scale.
Regression from canvas double buffering...
Assignee: nobody → bas
I can't reproduce this; Timothy, Chris, what version of OS X are you on?
See comment 5. This bug was fixed on nightly by bug 1150944. But you can reproduce again by setting gfx.canvas.azure.accelerated back to false. With that I'm able to reproduce on a retina screen on OS X 10.10 latest.
(In reply to Milan Sreckovic [:milan] from comment #11) > I can't reproduce this; Timothy, Chris, what version of OS X are you on? Like Timothy, I am using OS X 10.10.4 (on a Retina display) and can still reproduce this bug in Nightly 43 and Aurora 42 iff I force gfx.canvas.azure.accelerated = false.
Thanks, Bas knows what the problem is.
OS: Unspecified → Mac OS X
Attachment #8655685 - Flags: review?(jmuizelaar) → review+
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla43
Bas, is this fix safe for uplift to Beta41?
Comment on attachment 8655685 [details] [diff] [review] Don't forget the transform for canvases without an active target. Approval Request Comment [Feature/regressing bug #]: 1167235 [User impact if declined]: Drawing bugs [Describe test coverage new/current, TreeHerder]: Nightly coverage [Risks and why]: Very low, just initializes uninitialized variable [String/UUID change made/needed]: None
Comment on attachment 8655685 [details] [diff] [review] Don't forget the transform for canvases without an active target. This fix has been in Nightly for a week. Seems safe to uplift to Aurora42 and Beta41.
Please note that a Retina MacBook Pro is required in order to verify this fix.
QA Whiteboard: [good first verify]
This Bug's fix is verified in latest Firefox 44.0a2 Aurora Build Id: 20151029045227 User Agent: Mozilla/5.0 (X11; Linux i686; rv:44.0) Gecko/20100101 Firefox/44.0 [testday-20151030]
You need to log in before you can comment on or make changes to this bug.