1578598 - [Wayland+WebRender] Some elements aren't rendered when Xwayland is disabled

Status: RESOLVED WORKSFORME

(Core :: Graphics: WebRender, defect, P3)

Description

[Anders]

Attachment: screen_Sep-03-2019_16-58-15.jpeg

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:70.0) Gecko/20100101 Firefox/70.0

Steps to reproduce:

Set "gfx.webrender.all" to "true" in about:config.

This issue didn't exist before I upgraded to version 70 from 69 (Dev Edition) today. On version 69 I could use Wayland and WebRender with Xwayland disabled with no issues. This issue only occurs when Xwayland is disabled on version 70 and up.

Actual results:

Some elements in the browser frame and browsing window aren't getting rendered. I have attached an image of the bugzilla page to enter a bug report -- the page I'm typing this text into (https://bugzilla.mozilla.org/enter_bug.cgi#h=bugForm%7CFirefox).

Expected results:

These elements should be rendered.

Comment 1

[Jessie [:jbonisteel] pls NI]

Can you try using Mozregression to narrow in on a regression window since this seems like a new issue?

Comment 2

[Anders]

(In reply to Jessie [:jbonisteel] plz needinfo from comment #1)

Can you try using Mozregression to narrow in on a regression window since this seems like a new issue?

What a wonderful little tool.

9:03.66 INFO: Narrowed inbound regression window from [38ac0df0, e4b8e4d7] (3 builds) to [85b97b77, e4b8e4d7] (2 builds) (~1 steps left)
9:03.67 INFO: No more inbound revisions, bisection finished.
9:03.67 INFO: Last good revision: 85b97b773d19a567d1b91e1d538c73efe44df392
9:03.67 INFO: First bad revision: e4b8e4d71e5e78becd6feacbad4ae0e632f849f3
9:03.67 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=85b97b773d19a567d1b91e1d538c73efe44df392&tochange=e4b8e4d71e5e78becd6feacbad4ae0e632f849f3

Comment 3

[Sotaro Ikeda [:sotaro]]

:kvark, can you comment to the bug?

Comment 4

[Dzmitry Malyshau [:kvark]]

Thanks for finding the regression range!

Comment 5

[Dzmitry Malyshau [:kvark]]

Anders, would you be able to share a WR capture with us? To produce it, when you see the issue in Gecko, hit "CTRL + SHIFT + 3" combination. It's going to take several seconds to process, and you'll see a ~/wr-capture folder. Please zip it and share with us (i.e. by sending me a link to Firefox Send). Note: the WR capture doesn't contain any user information, it's a data slice of what's the browser rendering to screen.

Comment 6

[Anders]

(In reply to Dzmitry Malyshau [:kvark] from comment #5)

Anders, would you be able to share a WR capture with us? To produce it, when you see the issue in Gecko, hit "CTRL + SHIFT + 3" combination. It's going to take several seconds to process, and you'll see a ~/wr-capture folder. Please zip it and share with us (i.e. by sending me a link to Firefox Send). Note: the WR capture doesn't contain any user information, it's a data slice of what's the browser rendering to screen.

I'm trying this and I can't get Firefox to produce the ~/wr-capture folder while I have WebRender enabled and am experiencing the issue. To be sure it wasn't in a strange place, I ran find ~ -name *wr* after running the key combination and nothing showed up. AppArmor is disabled, it's a fresh profile, etc. I don't have anything bound to these keys anywhere else. Is there another way to do this? I tried searching online for perhaps a wiki page about taking a capture but couldn't find anything.

Comment 7

[Dzmitry Malyshau [:kvark]]

Thanks for trying, Anders!
It's unfortunate. Perhaps, something like a regional setting affected the bindings, not sure. I use CTRL + SHIFT + 3 on all systems in both dev builds and nightlies. Fwiw. it's described here - https://github.com/servo/webrender/wiki/Debugging-WebRender#capture-infrastructure

I'll try to get a setup locally to reproduce the issue myself.

Comment 8

[Anders]

Alright, sorry I couldn't get it to work. For what it's worth I tried it with a new profile and such under Weston and I still couldn't get wr-capture to work. However, Weston experiences the same "half-rendering" bug as sway.

Comment 10

[Val Packett]

hm, if this really doesn't happen when xwayland is enabled, could it have something to do with the GLXtest checks (bug 1570441)? i.e. some feature tests succeeding on the rust side but not the c++ side

Comment 11

[Val Packett]

Ha, yep, indeed. I'm currently writing a patch for bug 1556301. glxtest working and returning TFP TRUE and VERSION 4.0.0.0 fixed it. Though it seems like mHasTextureFromPixmap is a dead variable, I can't find anyone reading it. Maybe it's just the version and I need to test more carefully. The major version is indeed checked and if it's below 2 the code assumes ancient bad GL.

Comment 12

[Val Packett]

hm, copied the same build to my laptop, new observation: an extra restart is also required, i.e. the first MOZ_WEBRENDER=1 start of the new build still had the bug, second start worked fine. So maybe it's actually relying on some test result being stored permanently.

Comment 13

[Robert Mader [:rmader]]

Anders, you can still reproduce this? By now FF should not open any X11 connections any more in normal use (exception: WebRTC).

Comment 14

[Robert Mader [:rmader]]

Closing as likely fixed, please reopen if you still see this.