312.68 KB, image/png
974 bytes, text/html
30.59 KB, text/plain
350.51 KB, image/png
761 bytes, text/html
44 bytes, text/x-github-pull-request
|Details | Review | Splinter Review|
Zoom for extra-fun.
Attachment #9027488 - Attachment is obsolete: true
FWIW, I see corruption if I zoom-in . But it corrects itself if i scroll, or by itself after a few seconds. Corruption includes border corners corrupt, borders not drawing, wrong colour borders ni just to make sure you see this.
Yeah, that matches what I see. Thanks for checking! Good to know this is not specific to my machine. Jeff, should this be more than P4? I suspect it should, this is very visible in phabricator for example.
Flags: needinfo?(emilio) → needinfo?(jmuizelaar)
Reproducible on Win, Linux, Mac.
Keywords: correctness, testcase
OS: Unspecified → All
Priority: P4 → P3
I'll look at this given the other WR bits I wanted to look at are all clipping related and are mostly blocked on Dzmitry's work.
Assignee: nobody → emilio
(I totally forgot about this!)
Checkboxes of https://apps.nextcloud.com/apps/tasks are affected by this bug.
So at first I suspected this was due to incorrect border instance sharing due to the pixel scale not being included in the cache key directly, which can cause us to share a wrong border render task, but it seems it's at least partially (probably totally?) related to WR creating a separate surface for these elements, since I can reproduce with solid, non-rounded borders. The bug goes away if I comment out the opacity: 0.75 line (and load in a new profile of course). But it also reproduces with other ways of producing a surface like filter: *anything*, which right now always causes the creation of a different surface since we always pass a clip node, and WR has this code: https://searchfox.org/mozilla-central/rev/47edbd91c43db6229cf32d1fc4bae9b325b9e2d0/gfx/wr/webrender/src/display_list_flattener.rs#1267 So there's something going really bad here, and I don't really have much clue about what, I'll keep investigating.
Also the most annoying thing is that this reproduces since forever, so I couldn't even find a regression range...
Did a bit more thorough regression testing... Disappearing borders is bug 1494898: 8:02.19 INFO: Using local file: /tmp/tmphpGK_o/0fcb85b4c2f2--mozilla-inbound--target.tar.bz2 (downloaded in background) 8:02.19 INFO: Running mozilla-inbound build built on 2018-09-29 15:04:26.939000, revision 0fcb85b4 8:15.00 INFO: Launching /tmp/tmpcGl8Ac/firefox/firefox 8:15.00 INFO: Application command: /tmp/tmpcGl8Ac/firefox/firefox https://bug1503373.bmoattachments.org/attachment.cgi?id=9027493 -profile /tmp/tmpTjEZFt.mozrunner 8:15.01 INFO: application_buildid: 20180929144559 8:15.01 INFO: application_changeset: 0fcb85b4c2f2580df3de46af1c10b260dd156a44 8:15.01 INFO: application_name: Firefox 8:15.01 INFO: application_repository: https://hg.mozilla.org/integration/mozilla-inbound 8:15.01 INFO: application_version: 64.0a1 Was this inbound build good, bad, or broken? (type 'good', 'bad', 'skip', 'retry', 'back' or 'exit' and press Enter): good 8:25.07 INFO: Narrowed inbound regression window from [d799420c, f1dcdcc1] (3 builds) to [0fcb85b4, f1dcdcc1] (2 builds) (~1 steps left) 8:25.10 INFO: No more inbound revisions, bisection finished. 8:25.10 INFO: Last good revision: 0fcb85b4c2f2580df3de46af1c10b260dd156a44 8:25.10 INFO: First bad revision: f1dcdcc1674b19b6384f7354c4ac8a0f6896a1e5 8:25.10 INFO: Pushlog: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=0fcb85b4c2f2580df3de46af1c10b260dd156a44&tochange=f1dcdcc1674b19b6384f7354c4ac8a0f6896a1e5 Either the corruption there is not very evident / easy to trigger, or there's no corruption (just white borders). There's some regression between then and now where the corruption in the test-case becomes much more evident. I suspect that has to do with how we evict textures and such, but I didn't manage to determine a particular regression which regressed this. If someone wanted to give it a shot it'd be great. In any case looks like some of the changes in bug 1494898 made us evict stuff from the cache earlier or something... I'm still debugging.
A bit of rubber-duck debugging on IRC goes a long way \o/ https://mozilla.logbot.info/gfx/20181217#c15735061
Sorry for the lag here, was mostly on PTO last week :)
Status: NEW → RESOLVED
Last Resolved: 3 months ago
status-firefox64: --- → disabled
status-firefox65: --- → disabled
status-firefox66: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla66
Status: RESOLVED → VERIFIED
status-firefox66: fixed → verified
status-firefox67: --- → verified
You need to log in before you can comment on or make changes to this bug.