Debian Testing, Radeon RX480 fresh profile: layers.gpu-process.enabled, gfx.webrender.all > GP+[GFX1-]: WR: Unknown pipeline used for iframe IframeDisplayItem { clip_id: Clip(4, PipelineId(1, 1)), pipeline_id: PipelineId(1, 4) } Open a new tab, paste "about:support", press enter and scroll down to the graphics failure log. mozregression --good 2018-04-01 --bad 2018-04-13 --pref gfx.webrender.all:true layers.gpu-process.enabled:true startup.homepage_welcome_url:'https://example.com' > 8:23.84 INFO: Last good revision: a67e5015e4564bdb78d84765f9e4ff8580bda243 > 8:23.84 INFO: First bad revision: 0f807beef229718c015553bac09e4f638ca2add1 > 8:23.84 INFO: Pushlog: > https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=a67e5015e4564bdb78d84765f9e4ff8580bda243&tochange=0f807beef229718c015553bac09e4f638ca2add1 > 0f807beef229 Kartikaya Gupta — Bug 1452603 - Update Cargo lockfiles and re-vendor rust dependencies. r=jrmuizel > dd843b50cd36 Kartikaya Gupta — Bug 1452603 - Update Cargo stuff for the serde bump. r=jrmuizel > 50c382ab757a Kartikaya Gupta — Bug 1452603 - Update webrender to commit 6f997974cec5772b1797725f4a7942d742e7d7ff. r=jrmuize try builds from bug 1452603: > WR @ 844639034764679b23aaae14cbf6981c8c060b80 mozregression --repo try --launch 1dd7c19e836fa0b1aba0e646a1fe3288554455be --pref gfx.webrender.all:true layers.gpu-process.enabled:true startup.homepage_welcome_url:'https://example.com' good > WR @ 86ca11b1ac79c5ee733de4b293c34de5d77419a1 mozregression --repo try --launch e3a87b9e25e0bb86e9d74e777778e9fea231b088 --pref gfx.webrender.all:true layers.gpu-process.enabled:true startup.homepage_welcome_url:'https://example.com' bad "Regression" range: https://github.com/servo/webrender/compare/844639034764679b23aaae14cbf6981c8c060b80...86ca11b1ac79c5ee733de4b293c34de5d77419a1 https://github.com/servo/webrender/pull/2647 introduced > error!("Unknown pipeline used for iframe {:?}", info); I can't reproduce this without gpu process.

This is basically what's causing the flickering of https://bugzilla.mozilla.org/show_bug.cgi?id=1448896 I just added a warning earlier in the code to catch that. At the end of the day we may switch this to a hard error. kats, why is this a blocker for 1452603 though?

> why is this a blocker for 1452603 though? bug 1452603 caused a failure on about:support, so I perceived this as regression (at first). When I found #2647 I realized that this message has been introduced with intention to fight bad things, so I put the "Regression" from "Regression range" in quotes. While filing this bug I asked myself whether I should put bug 1452603 into "Blocks" or "See Also". What would be right here?

(In reply to Jan Andre Ikenmeyer [:darkspirit] from comment #2) > While filing this bug I asked myself whether I should put > bug 1452603 into "Blocks" or "See Also". What would be right here? If this were a real regression then yes, marking it blocking bug 1452603 (which introduced the behaviour) would be correct. In this case, the behaviour is just a println that now shows up for what was a pre-existing bug. So the workflow is less obvious. Really we want to fix the pre-existing bug and leave the println in place. I'm ok with leaving it as blocking, just as long as we are clear that the thing we want to fix is a pre-existing issue.

I see this error constantly on linux without gpu process enabled (~ half a dozen times per page load), even with a fresh profile. Separate bug or should I wait for progress on this one?

@johnp: Wait for this one. Sotaro, it looks like bug 1448896 didn't fix all instances of this problem. Any thoughts on how we can track down and fix the rest?

Before looking into the problem, I faced another problem. about:support seemed to be broken. The following is mozregression result. 7:06.28 INFO: No more inbound revisions, bisection finished. 7:06.28 INFO: Last good revision: f291b07fa1f869fd3f9af9f5fe940d47b842edcf 7:06.28 INFO: First bad revision: 98389f291fe61e622267ba3e5e99792e6f5d6350 7:06.30 INFO: Pushlog: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=f291b07fa1f869fd3f9af9f5fe940d47b842edcf&tochange=98389f291fe61e622267ba3e5e99792e6f5d6350

(In reply to Sotaro Ikeda [:sotaro] from comment #6) > Before looking into the problem, I faced another problem. about:support > seemed to be broken. The following is mozregression result. > > 7:06.28 INFO: No more inbound revisions, bisection finished. > 7:06.28 INFO: Last good revision: f291b07fa1f869fd3f9af9f5fe940d47b842edcf > 7:06.28 INFO: First bad revision: 98389f291fe61e622267ba3e5e99792e6f5d6350 > 7:06.30 INFO: Pushlog: > https://hg.mozilla.org/integration/mozilla-inbound/ > pushloghtml?fromchange=f291b07fa1f869fd3f9af9f5fe940d47b842edcf&tochange=9838 > 9f291fe61e622267ba3e5e99792e6f5d6350 I confirmed that Bug 1420908 broke about:support by locally backing out the change.

(In reply to Sotaro Ikeda [:sotaro] from comment #7) > I confirmed that Bug 1420908 broke about:support by locally backing out the > change. Bug 1454416 was created for it.

When I tested locally on linux, pipeline ids of errors were always "PipelineId(1, *)". "PipelineSourceId mNamespace" of PipelineId was always 1. The pipeline ids are always allocated for WebRenderBridgeParent.

IframeDisplayItem for WebRenderBridgeParent is pushed at nsDisplayRemote::CreateWebRenderCommands() in chrome process. https://dxr.mozilla.org/mozilla-central/source/layout/ipc/RenderFrameParent.cpp#394 DisplayList of pipelines of non-root WebRenderBridgeParent is pushed by WebRenderBridgeParent. It is triggered by content process. The DisplayList is delivered like WebRenderBridgeChild -> WebRenderBridgeParent -> WebRenderAPI::SendTransaction() ->---> Scene::set_display_list(). IframeDisplayItem and DisplayList of pipelines are triggered in different process. Therefore there could be a case that DisplayList of pipeline was not set, when IframeDisplayItem was handled in DisplayListFlattener::flatten_iframe(). https://dxr.mozilla.org/mozilla-central/source/gfx/webrender/src/display_list_flattener.rs#571

With attachment 8968416 [details] [diff] [review], I confirmed the following two cases that caused error logs. - [1] WebRenderBridgeParent of related pipeline was created, but it do not received DisplayList from WebRenderBridgeChild in content process yet. Then its IframeDisplayItem was handled in DisplayListFlattener::flatten_iframe() in WebRender. - [2] WebRenderBridgeParent was destroyed and its namespace was removed from WebRender. Then Then its IframeDisplayItem was handled in DisplayListFlattener::flatten_iframe() in WebRender. From current gecko's architecture, it seems not easy to prevent the situation. One solution might be to push dummy DisplayList for the pipelines.

Presumably this happens with non-webrender as well, but we just ignore the situations [1] and return gracefully. So maybe we should do the same in webrender, for the case where the IframeDisplayItem points to an out-of-process pipeline. for in-process pipelines (like async images and such) we probably still want the error because in those cases there might be user-visible issues like the flickering that was fixed in the previous bug. [1] https://searchfox.org/mozilla-central/rev/a30a60eadcff99d2a043241955d215dbeccad876/gfx/layers/composite/AsyncCompositionManager.cpp#126,131

This seems to be happening a lot still, and I looked into one instance of it that I can reproduce locally while running a reftest. What happens is that the display list contains canvases, which we handle as async images. the EndTransaction message contains the right display list and WebRenderParentCommand objects, but then on the parent side the WebRenderParentCommands are used to update the state in AsyncImagePipelineManager [1] while the display list is sent directly to WR [2]. The contents of the pipelines are not sent to WR until later, just before the GenerateFrame transaction at [3]. When the scene building step happens in WR it tries to flatten the iframes from the display list and it spits out this error, because it doesn't have the pipeline contents yet. [1] https://searchfox.org/mozilla-central/rev/b28b94dc81d60c6d9164315adbd4a5073526d372/gfx/layers/wr/WebRenderBridgeParent.cpp#621 [2] https://searchfox.org/mozilla-central/rev/b28b94dc81d60c6d9164315adbd4a5073526d372/gfx/layers/wr/WebRenderBridgeParent.cpp#651-655 [3] https://searchfox.org/mozilla-central/rev/b28b94dc81d60c6d9164315adbd4a5073526d372/gfx/layers/wr/WebRenderBridgeParent.cpp#1293

The spew from this warning is getting quite annoying. I think what I would like to do is to make some kinds of iframe items have "ignorable" pipeline ids (the ones that are actual remote iframes in gecko). For piplines that are from async images we can then promote the warning to an error (since I think I fixed all of those).

Comment on attachment 8976992 [details] Bug 1454042 - Allow missing pipeline information for cross-process iframes. https://reviewboard.mozilla.org/r/245124/#review251204 Nice!

Pushed by kgupta@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/75146e6b8a3b Allow missing pipeline information for cross-process iframes. r=sotaro