Closed
Bug 1503373
Opened 6 years ago
Closed 6 years ago
Sporadic border corruption.
Categories
(Core :: Graphics: WebRender, defect, P3)
Tracking
()
VERIFIED
FIXED
mozilla66
People
(Reporter: emilio, Assigned: emilio)
References
Details
(Keywords: correctness, testcase)
Attachments
(6 files, 1 obsolete file)
I haven't found STR, but from time to time some borders look wrong, see screenshot.
In particular, see how the bottom borders are off, either white or displaying content from another part of the page.
Updated•6 years ago
|
Updated•6 years ago
|
Blocks: stage-wr-trains
Priority: -- → P4
Assignee | ||
Comment 1•6 years ago
|
||
Assignee | ||
Comment 2•6 years ago
|
||
Zoom for extra-fun.
Attachment #9027488 -
Attachment is obsolete: true
Comment 3•6 years ago
|
||
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.
Flags: needinfo?(emilio)
Comment 4•6 years ago
|
||
Comment 5•6 years ago
|
||
various type of corruptions
It helps to zoom-in, and then either switch tabs or switch to another application to repro
Assignee | ||
Comment 6•6 years ago
|
||
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)
Comment 7•6 years ago
|
||
Reproducible on Win, Linux, Mac.
Keywords: correctness,
testcase
OS: Unspecified → All
Assignee | ||
Comment 9•6 years ago
|
||
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
Assignee | ||
Updated•6 years ago
|
Flags: needinfo?(emilio)
Assignee | ||
Comment 10•6 years ago
|
||
(I totally forgot about this!)
Comment 11•6 years ago
|
||
Checkboxes of https://apps.nextcloud.com/apps/tasks are affected by this bug.
Assignee | ||
Comment 12•6 years ago
|
||
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.
Assignee | ||
Comment 13•6 years ago
|
||
Also the most annoying thing is that this reproduces since forever, so I couldn't even find a regression range...
Assignee | ||
Comment 14•6 years ago
|
||
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.
Assignee | ||
Comment 15•6 years ago
|
||
A bit of rubber-duck debugging on IRC goes a long way \o/
https://mozilla.logbot.info/gfx/20181217#c15735061
Assignee | ||
Comment 16•6 years ago
|
||
Flags: needinfo?(emilio)
Assignee | ||
Comment 17•6 years ago
|
||
Sorry for the lag here, was mostly on PTO last week :)
Updated•6 years ago
|
Status: NEW → RESOLVED
Closed: 6 years ago
status-firefox64:
--- → disabled
status-firefox65:
--- → disabled
status-firefox66:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla66
Comment 22•6 years ago
|
||
Hi, This issue is Verified as Fixed in Nightly 67.0a1 (2019-02-07) as well as Beta 66.0b5, I will mark this issue accordingly.
Assignee | ||
Updated•5 years ago
|
You need to log in
before you can comment on or make changes to this bug.
Description
•