Closed Bug 1547351 Opened 1 year ago Closed 1 year ago

Contents on popup of Addons are shown as white when gfx.webrender.split-render-roots is true

Categories

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

Unspecified
Windows
defect

Tracking

()

VERIFIED FIXED
mozilla68
Tracking Status
firefox-esr60 --- unaffected
firefox-esr68 --- disabled
firefox68 --- disabled
firefox69 --- disabled
firefox70 --- fixed

People

(Reporter: yamadat501, Assigned: Gankra)

References

Details

(Keywords: platform-parity)

Attachments

(7 files, 3 obsolete files)

Attached image popup_bug.jpg

Similar bugs like Bug 1512998 have been reported, but I report this as new bug because this bug trigger is different from others.

STR:

  1. Install ublock origin and set its toolbar icon.
  2. Set gfx.webrender.split-render-roots true.
  3. Open ublock origin's popup by clicking icon.

Expected result:
Contents on popup are shown.

Actual result:
Contents on popup are white(But works normally)

Priority: -- → P3

Not reproducible on Macbook with Nightly 68.0a1 (2019-04-30) (64-Bit)
built from https://hg.mozilla.org/mozilla-central/rev/90234f4c094dcc794df28fdd464793dfe065f943.

At least, I can reproduce on Windows10.
Build ID 20190430121130
User Agent Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Firefox/68.0

Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: platform-parity
OS: Unspecified → Windows
Assignee: nobody → dothayer

I'm not sure when/if this stopped working, but it appears the -moz-stack
display of the stack element doesn't send us through the admittedly
brittle pathways that allow us to create nsDisplayRenderRoots. This
brittleness is a consequence of copying the use of the "layer"
attribute and is discussed in the core document splitting bug. It's
outside the scope of this bug to fix that.

Please advise if there is a better alternative. After ensuring that
extension popups are wired up to create an nsDisplayRenderRoot, the
bottom bit of the popup's content is cut off. This fixes that issue,
but I'm not certain if it is the most robust option.

Depends on D31006

Pushed by dothayer@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/888907b9ffc3
Set renderroot of extension popup on browser element r=mattwoodrow
https://hg.mozilla.org/integration/autoland/rev/cb6320b272f9
Use offset relative to reference frame for nsDisplayRenderRoot r=mattwoodrow
Status: NEW → RESOLVED
Closed: 1 year ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla68

I checked 20190517214313 nightly(rev 1ae707852b608ea77dc82c892f25e169cbc316b5) contains these patches and the problem still happened for me.

I also reproduce the problem.
Build ID 20190517214313
User Agent Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Firefox/68.0
Built from: https://hg.mozilla.org/mozilla-central/rev/1ae707852b608ea77dc82c892f25e169cbc316b5

Status: RESOLVED → REOPENED
Resolution: FIXED → ---

I see the same issue without enabling splitting. The panel is white and gets drawn on hover. I wonder if it's a different bug.

Hmm. The fix is working for me on OSX where I developed it, but not on Windows. Taking another look. If anyone is still experiencing this on OSX though please let me know.

Matt, I'm thinking this might be the wrong approach overall. Right now we have to play whack-a-mole with all the things that house stuff rendered in a content process, but I think it's going to make more sense long-term if we think of it more on an opt-in basis. "Normal" content in a window that has chrome at the top should get a render root of content, and everything else, be it the contents of a WebExtensions popup or the contents of a picture-in-picture player, should get a default render root. However, I don't know of any way to conveniently access that information. I don't suppose you might?

Specifically, I think it would be nice if I could ask "is this normal content?" either in WebRenderLayerManager or in WebRenderBridgeParent. I don't suppose you have any ideas on this?

Flags: needinfo?(matt.woodrow)

Can we avoid content needing to know which RenderRoot it belongs to?

It seems that content knows which iframe it belongs to (PipelineId), and the parent process knows which iframes belong to which RenderRoot.

So it seems like a parent SetDisplayList call (for a given RenderRoot) could include a list of what iframes are within that DL.

Then when we get a new DL from content, we can ask the root WebRenderBridgeParent which RenderRoot we belong to, and access the appropriate WrAPI.

Flags: needinfo?(matt.woodrow)

(In reply to Matt Woodrow (:mattwoodrow) from comment #12)

Can we avoid content needing to know which RenderRoot it belongs to?

It seems that content knows which iframe it belongs to (PipelineId), and the parent process knows which iframes belong to which RenderRoot.

So it seems like a parent SetDisplayList call (for a given RenderRoot) could include a list of what iframes are within that DL.

Then when we get a new DL from content, we can ask the root WebRenderBridgeParent which RenderRoot we belong to, and access the appropriate WrAPI.

Are there potential ordering difficulties here? Can I always guarantee that the display list containing the iframe comes in before the content display list? Assuming yes, it would also be simplest if I could just do this by setting CompositorBridgeParent::GetIndirectShadowTree(remoteLayersId)->mWrBridge->mRenderRoot from the root WebRenderBridgeParent's RecvSetDisplayList, but that only works if I can guarantee that the content WebRenderBridgeParent has been created by the time we get the displaylist containing the iframe.

Flags: needinfo?(matt.woodrow)

(In reply to Doug Thayer [:dthayer] from comment #13)

Are there potential ordering difficulties here? Can I always guarantee that the display list containing the iframe comes in before the content display list? Assuming yes, it would also be simplest if I could just do this by setting CompositorBridgeParent::GetIndirectShadowTree(remoteLayersId)->mWrBridge->mRenderRoot from the root WebRenderBridgeParent's RecvSetDisplayList, but that only works if I can guarantee that the content WebRenderBridgeParent has been created by the time we get the displaylist containing the iframe.

Yeah, I think that can happen (and probably does, I think we try to pre-render content when tab switching).

That's a bit of a problem, since it probably also means we can't have the parent notify content of which RR it belongs to.

Having the content process try to guess, and trying to keep them in sync feels pretty error prone though :(

Flags: needinfo?(matt.woodrow)

(In reply to Matt Woodrow (:mattwoodrow) from comment #14)

Yeah, I think that can happen (and probably does, I think we try to pre-render content when tab switching).

That's a bit of a problem, since it probably also means we can't have the parent notify content of which RR it belongs to.

Having the content process try to guess, and trying to keep them in sync feels pretty error prone though :(

Hmm, can we just defer processing a display list in WebRenderBridgeParent::RecvSetDisplayList if we haven't yet received an indication of where it belongs? I'm not sure exactly what that would look like - moving the whole RenderRootDisplayListData into a map somewhere, and making sure we clear it out if we get a DeallocateLayerTreeId?

Kats, does that sound basically sane or no?

Flags: needinfo?(kats)

(In reply to Matt Woodrow (:mattwoodrow) from comment #14)

Yeah, I think that can happen (and probably does, I think we try to pre-render content when tab switching).

So yes, that's true, but IIRC in this situation we never actually do anything with the content display list. Because it's not attached anywhere to the parent display list, it doesn't participate in the scene build or rendering, it mostly just gets ignored on the WR side until the parent-side DL with the iframe element shows up.

(In reply to Doug Thayer [:dthayer] from comment #15)

Hmm, can we just defer processing a display list in WebRenderBridgeParent::RecvSetDisplayList if we haven't yet received an indication of where it belongs? I'm not sure exactly what that would look like - moving the whole RenderRootDisplayListData into a map somewhere, and making sure we clear it out if we get a DeallocateLayerTreeId?

Kats, does that sound basically sane or no?

... so I think this does sound basically sane, but it's going to add yet more implementation complexity. But absent a better solution (which I can't think of right now, given it's Friday evening) it sounds like something worth trying.

Flags: needinfo?(kats)

(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #16)

... so I think this does sound basically sane, but it's going to add yet more implementation complexity. But absent a better solution (which I can't think of right now, given it's Friday evening) it sounds like something worth trying.

Quick update so no one's in the dark: turns out this is super annoying to do. Still working out all of the kinks and not sure when they'll stop popping up.

This implements the idea of automatically setting a content proc's
render root based on the render root enclosing the iframe that
points to it. There was a bit of cleanup in here that was a bit
tricky to extract from the core patch revolving around how we
use the Api(...) helper. This was to avoid the situation where
we use the Api(...) helper before our render root is initialized,
when we don't actually have to. I.e., when we just want the root
WebRenderAPI in all cases.

An alternative to this approach could be to fully built out the
WebRender transactions and just queue those up to be sent. However,
transaction building has various side effects which are committed
before the transaction is actually sent, so we would have to build
out some scheme for deferring those as well. This seemed simpler.

This splits out the inner bit of RecvEmptyTransaction to just iterate over
the documents once, rather than iterating over them individually. Originally
I ran into difficulties with this and then left it on the table, but I think
it was enabled by splitting out the epochs in pipeline info by renderroot.

Per IRC, :kats could you get this over the line (or if not, can you suggest someone else)? :-)

Flags: needinfo?(kats)

I could, but I likely won't be around to deal with any fallout that results. I think it would be better if Gankro took this as a way to get more familiarized with the document-splitting code, since I believe she will be owner/operator of that code while I'm away.

Flags: needinfo?(kats) → needinfo?(a.beingessner)
Assignee: dothayer → a.beingessner

Patch primarily written by :dthayer

Flags: needinfo?(a.beingessner)

not sure how to get phabricator to properly land these two patches in the right way

Attachment #9069787 - Attachment is obsolete: true
Pushed by abeingessner@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/69260373f95c
Factor out RecvEmptyTransaction's core transaction building r=sotaro
https://hg.mozilla.org/integration/autoland/rev/b294575c279c
Automatically set content process render root r=kats

Backed out 2 changesets (bug 1547351) for build bustages at WebRenderBridgeParent.cpp on a CLOSED TREE.

Backout link: https://hg.mozilla.org/integration/autoland/rev/93a98b25c217936992d564b85ff3b706bf2eb93e

**Push with failures:**https://treeherder.mozilla.org/#/jobs?repo=autoland&group_state=expanded&resultStatus=testfailed%2Cbusted%2Cexception&revision=b294575c279c9681d0a26b1592f47014262f1d03&selectedJob=256108236

Log link: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=256108236&repo=autoland&lineNumber=18262

Log snippet:

[task 2019-07-12T03:39:55.289Z] 03:39:55 INFO - dom/clients/manager/Unified_cpp_dom_clients_manager0.o
[task 2019-07-12T03:39:55.289Z] 03:39:55 INFO - make[4]: Leaving directory '/builds/worker/workspace/build/src/obj-firefox/dom/clients/manager'
[task 2019-07-12T03:39:55.567Z] 03:39:55 INFO - make[4]: Entering directory '/builds/worker/workspace/build/src/obj-firefox/gfx/layers'
[task 2019-07-12T03:39:55.567Z] 03:39:55 INFO - /builds/worker/workspace/build/src/sccache/sccache /builds/worker/workspace/build/src/clang/bin/clang++ -isysroot /builds/worker/workspace/build/src/MacOSX10.11.sdk --target=x86_64-apple-darwin -o Unified_cpp_gfx_layers12.o -c -fvisibility=hidden -fvisibility-inlines-hidden -DDEBUG=1 -DGOOGLE_PROTOBUF_NO_RTTI -DGOOGLE_PROTOBUF_NO_STATIC_INITIALIZER -DOS_POSIX=1 -DOS_MACOSX=1 -DD3D_DEBUG_INFO -DSTATIC_EXPORTABLE_JS_API -DMOZ_HAS_MOZGLUE -DMOZILLA_INTERNAL_API -DIMPL_LIBXUL -I/builds/worker/workspace/build/src/gfx/layers -I/builds/worker/workspace/build/src/obj-firefox/gfx/layers -I/builds/worker/workspace/build/src/obj-firefox/ipc/ipdl/_ipdlheaders -I/builds/worker/workspace/build/src/ipc/chromium/src -I/builds/worker/workspace/build/src/ipc/glue -I/builds/worker/workspace/build/src/docshell/base -I/builds/worker/workspace/build/src/layout/base -I/builds/worker/workspace/build/src/layout/generic -I/builds/worker/workspace/build/src/media/libyuv/libyuv/include -I/builds/worker/workspace/build/src/gfx/skia -I/builds/worker/workspace/build/src/gfx/skia/skia/include/config -I/builds/worker/workspace/build/src/gfx/skia/skia/include/core -I/builds/worker/workspace/build/src/gfx/skia/skia/include/docs -I/builds/worker/workspace/build/src/gfx/skia/skia/include/gpu -I/builds/worker/workspace/build/src/gfx/skia/skia/include/utils -I/builds/worker/workspace/build/src/obj-firefox/dist/include -I/builds/worker/workspace/build/src/obj-firefox/dist/include/nspr -I/builds/worker/workspace/build/src/obj-firefox/dist/include/nss -fPIC -DMOZILLA_CLIENT -include /builds/worker/workspace/build/src/obj-firefox/mozilla-config.h -Qunused-arguments -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -fstack-protector-strong -Qunused-arguments -Wall -Wbitfield-enum-conversion -Wempty-body -Wignored-qualifiers -Woverloaded-virtual -Wpointer-arith -Wshadow-field-in-constructor-modified -Wsign-compare -Wtype-limits -Wunreachable-code -Wunreachable-code-return -Wwrite-strings -Wno-invalid-offsetof -Wclass-varargs -Wfloat-overflow-conversion -Wfloat-zero-conversion -Wloop-analysis -Wc++1z-compat -Wc++2a-compat -Wcomma -Wimplicit-fallthrough -Werror=non-literal-null-conversion -Wstring-conversion -Wtautological-overlap-compare -Wtautological-unsigned-enum-zero-compare -Wtautological-unsigned-zero-compare -Wno-inline-new-delete -Wno-error=deprecated-declarations -Wno-error=array-bounds -Wno-error=backend-plugin -Wno-error=return-std-move -Wno-error=atomic-alignment -Wformat -Wformat-security -Wno-gnu-zero-variadic-macro-arguments -Wno-unknown-warning-option -Wno-return-type-c-linkage -fno-sized-deallocation -fcrash-diagnostics-dir=/builds/worker/artifacts -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -fstack-protector-strong -fno-exceptions -fno-strict-aliasing -stdlib=libc++ -fno-rtti -ffunction-sections -fdata-sections -fno-exceptions -fno-math-errno -pthread -pipe -g -Xclang -load -Xclang /builds/worker/workspace/build/src/obj-firefox/build/clang-plugin/libclang-plugin.so -Xclang -add-plugin -Xclang moz-check -O3 -fno-omit-frame-pointer -funwind-tables -Werror -I/builds/worker/workspace/build/src/obj-firefox/dist/include/cairo -Wno-error=shadow -Wno-maybe-uninitialized -MD -MP -MF .deps/Unified_cpp_gfx_layers12.o.pp /builds/worker/workspace/build/src/obj-firefox/gfx/layers/Unified_cpp_gfx_layers12.cpp
[task 2019-07-12T03:39:55.567Z] 03:39:55 INFO - In file included from /builds/worker/workspace/build/src/obj-firefox/gfx/layers/Unified_cpp_gfx_layers12.cpp:2:
[task 2019-07-12T03:39:55.568Z] 03:39:55 ERROR - /builds/worker/workspace/build/src/gfx/layers/wr/WebRenderBridgeParent.cpp:401:19: error: no template named 'InfallibleTArray'; did you mean 'FallibleTArray'?
[task 2019-07-12T03:39:55.569Z] 03:39:55 INFO - p, key, InfallibleTArray<RenderRootDeferredData>());
[task 2019-07-12T03:39:55.570Z] 03:39:55 INFO - ^~~~~~~~~~~~~~~~
[task 2019-07-12T03:39:55.570Z] 03:39:55 INFO - FallibleTArray
[task 2019-07-12T03:39:55.571Z] 03:39:55 INFO - /builds/worker/workspace/build/src/obj-firefox/dist/include/nsTArray.h:2477:7: note: 'FallibleTArray' declared here
[task 2019-07-12T03:39:55.572Z] 03:39:55 INFO - class FallibleTArray : public nsTArray_Impl<E, nsTArrayFallibleAllocator> {
[task 2019-07-12T03:39:55.573Z] 03:39:55 INFO - ^
[task 2019-07-12T03:39:55.574Z] 03:39:55 INFO - In file included from /builds/worker/workspace/build/src/obj-firefox/gfx/layers/Unified_cpp_gfx_layers12.cpp:2:
[task 2019-07-12T03:39:55.575Z] 03:39:55 ERROR - /builds/worker/workspace/build/src/gfx/layers/wr/WebRenderBridgeParent.cpp:369:55: error: Refcounted variable 'this' of type 'mozilla::layers::WebRenderBridgeParent' cannot be captured by a lambda
[task 2019-07-12T03:39:55.575Z] 03:39:55 INFO - wr::IpcResourceUpdateQueue::ReleaseShmems(this, x.mSmallShmems);

Flags: needinfo?(a.beingessner)
Pushed by abeingessner@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/94db0d98be90
Factor out RecvEmptyTransaction's core transaction building r=sotaro
https://hg.mozilla.org/integration/autoland/rev/af34904f00c7
Automatically set content process render root r=kats
Backout by ccoroiu@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/2712a68bfcfa
Backed out 2 changesets for build bustage at gfx/layers/wr/WebRenderBridgeParent.cpp on a CLOSED TREE

Backed out 2 changesets (bug 1547351) for build bustage at gfx/layers/wr/WebRenderBridgeParent.cpp

Backout: https://hg.mozilla.org/integration/autoland/rev/2712a68bfcfa76bb42c91db1a0db6676543f8d59

Failure push: https://treeherder.mozilla.org/#/jobs?repo=autoland&revision=af34904f00c78daa52ed7970f64bbdd152acd508

Failure log: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=256121774&repo=autoland&lineNumber=18821

task 2019-07-12T05:27:14.704Z] 05:27:14 INFO - make[4]: Entering directory '/builds/worker/workspace/build/src/obj-firefox/dom/indexedDB'
[task 2019-07-12T05:27:14.704Z] 05:27:14 INFO - mkdir -p '.deps/'
[task 2019-07-12T05:27:14.704Z] 05:27:14 INFO - make[4]: Leaving directory '/builds/worker/workspace/build/src/obj-firefox/dom/indexedDB'
[task 2019-07-12T05:27:14.704Z] 05:27:14 INFO - make[4]: Entering directory '/builds/worker/workspace/build/src/obj-firefox/dom/indexedDB'
[task 2019-07-12T05:27:14.705Z] 05:27:14 INFO - dom/indexedDB/ActorsParent.o
[task 2019-07-12T05:27:14.705Z] 05:27:14 INFO - make[4]: Leaving directory '/builds/worker/workspace/build/src/obj-firefox/dom/indexedDB'
[task 2019-07-12T05:27:14.761Z] 05:27:14 INFO - make[4]: Entering directory '/builds/worker/workspace/build/src/obj-firefox/gfx/layers'
[task 2019-07-12T05:27:14.773Z] 05:27:14 INFO - /builds/worker/workspace/build/src/sccache/sccache /builds/worker/workspace/build/src/clang/bin/clang++ --target=arm-linux-androideabi -o Unified_cpp_gfx_layers12.o -c -flto=thin -I/builds/worker/workspace/build/src/obj-firefox/dist/stl_wrappers -I/builds/worker/workspace/build/src/obj-firefox/dist/system_wrappers -include /builds/worker/workspace/build/src/config/gcc_hidden.h -DNDEBUG=1 -DTRIMMED=1 -DGOOGLE_PROTOBUF_NO_RTTI -DGOOGLE_PROTOBUF_NO_STATIC_INITIALIZER -DOS_POSIX=1 -DOS_LINUX=1 -DSTATIC_EXPORTABLE_JS_API -DMOZ_HAS_MOZGLUE -DMOZILLA_INTERNAL_API -DIMPL_LIBXUL -I/builds/worker/workspace/build/src/gfx/layers -I/builds/worker/workspace/build/src/obj-firefox/gfx/layers -I/builds/worker/workspace/build/src/obj-firefox/ipc/ipdl/ipdlheaders -I/builds/worker/workspace/build/src/ipc/chromium/src -I/builds/worker/workspace/build/src/ipc/glue -I/builds/worker/workspace/build/src/docshell/base -I/builds/worker/workspace/build/src/layout/base -I/builds/worker/workspace/build/src/layout/generic -I/builds/worker/workspace/build/src/media/libyuv/libyuv/include -I/builds/worker/workspace/build/src/gfx/skia -I/builds/worker/workspace/build/src/gfx/skia/skia/include/config -I/builds/worker/workspace/build/src/gfx/skia/skia/include/core -I/builds/worker/workspace/build/src/gfx/skia/skia/include/docs -I/builds/worker/workspace/build/src/gfx/skia/skia/include/gpu -I/builds/worker/workspace/build/src/gfx/skia/skia/include/utils -I/builds/worker/workspace/build/src/obj-firefox/dist/include -I/builds/worker/workspace/build/src/obj-firefox/dist/include/nspr -I/builds/worker/workspace/build/src/obj-firefox/dist/include/nss -fPIC -DMOZILLA_CLIENT -include /builds/worker/workspace/build/src/obj-firefox/mozilla-config.h -Qunused-arguments -isystem /builds/worker/workspace/build/src/android-ndk/sysroot/usr/include/arm-linux-androideabi -isystem /builds/worker/workspace/build/src/android-ndk/sysroot/usr/include -gcc-toolchain /builds/worker/workspace/build/src/android-ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64 -D__ANDROID_API_=16 -fstack-protector-strong -Qunused-arguments -Wall -Wbitfield-enum-conversion -Wempty-body -Wignored-qualifiers -Woverloaded-virtual -Wpointer-arith -Wshadow-field-in-constructor-modified -Wsign-compare -Wtype-limits -Wunreachable-code -Wunreachable-code-return -Wwrite-strings -Wno-invalid-offsetof -Wclass-varargs -Wfloat-overflow-conversion -Wfloat-zero-conversion -Wloop-analysis -Wc++1z-compat -Wc++2a-compat -Wcomma -Wimplicit-fallthrough -Werror=non-literal-null-conversion -Wstring-conversion -Wtautological-overlap-compare -Wtautological-unsigned-enum-zero-compare -Wtautological-unsigned-zero-compare -Wno-inline-new-delete -Wno-error=deprecated-declarations -Wno-error=array-bounds -Wno-error=backend-plugin -Wno-error=return-std-move -Wno-error=atomic-alignment -Wformat -Wformat-security -Wno-gnu-zero-variadic-macro-arguments -Wno-unknown-warning-option -Wno-return-type-c-linkage -mno-unaligned-access -fno-sized-deallocation -fno-short-enums -fno-exceptions -stdlib=libstdc++ -I/builds/worker/workspace/build/src/android-ndk/sources/cxx-stl/llvm-libc++/include -I/builds/worker/workspace/build/src/android-ndk/sources/android/support/include -I/builds/worker/workspace/build/src/android-ndk/sources/cxx-stl/llvm-libc++abi/include -march=armv7-a -mthumb -mfpu=neon -mfloat-abi=softfp -fstack-protector-strong -fno-exceptions -fno-strict-aliasing -fno-rtti -ffunction-sections -fdata-sections -fno-exceptions -fno-math-errno -pipe -g -Xclang -load -Xclang /builds/worker/workspace/build/src/obj-firefox/build/clang-plugin/libclang-plugin.so -Xclang -add-plugin -Xclang moz-check -Oz -fno-omit-frame-pointer -funwind-tables -Werror -I/builds/worker/workspace/build/src/obj-firefox/dist/include/cairo -I/builds/worker/workspace/build/src/obj-firefox/dist/include/cairo -Wno-error=shadow -Wno-maybe-uninitialized -MD -MP -MF .deps/Unified_cpp_gfx_layers12.o.pp /builds/worker/workspace/build/src/obj-firefox/gfx/layers/Unified_cpp_gfx_layers12.cpp
[task 2019-07-12T05:27:14.773Z] 05:27:14 INFO - In file included from /builds/worker/workspace/build/src/obj-firefox/gfx/layers/Unified_cpp_gfx_layers12.cpp:20:
[task 2019-07-12T05:27:14.774Z] 05:27:14 ERROR - /builds/worker/workspace/build/src/gfx/layers/wr/WebRenderBridgeParent.cpp:369:55: error: Refcounted variable 'this' of type 'mozilla::layers::WebRenderBridgeParent' cannot be captured by a lambda
[task 2019-07-12T05:27:14.774Z] 05:27:14 INFO - wr::IpcResourceUpdateQueue::ReleaseShmems(this, x.mSmallShmems);
[task 2019-07-12T05:27:14.774Z] 05:27:14 INFO - ^
[task 2019-07-12T05:27:14.775Z] 05:27:14 INFO - /builds/worker/workspace/build/src/gfx/layers/wr/WebRenderBridgeParent.cpp:369:55: note: Please consider using a smart pointer
[task 2019-07-12T05:27:14.775Z] 05:27:14 ERROR - /builds/worker/workspace/build/src/gfx/layers/wr/WebRenderBridgeParent.cpp:373:55: error: Refcounted variable 'this' of type 'mozilla::layers::WebRenderBridgeParent' cannot be captured by a lambda
[task 2019-07-12T05:27:14.775Z] 05:27:14 INFO - wr::IpcResourceUpdateQueue::ReleaseShmems(this, x.mSmallShmems);
[task 2019-07-12T05:27:14.776Z] 05:27:14 INFO - ^
[task 2019-07-12T05:27:14.776Z] 05:27:14 INFO - /builds/worker/workspace/build/src/gfx/layers/wr/WebRenderBridgeParent.cpp:373:55: note: Please consider using a smart pointer
[task 2019-07-12T05:27:14.777Z] 05:27:14 ERROR - /builds/worker/workspace/build/src/gfx/layers/wr/WebRenderBridgeParent.cpp:377:55: error: Refcounted variable 'this' of type 'mozilla::layers::WebRenderBridgeParent' cannot be captured by a lambda
[task 2019-07-12T05:27:14.777Z] 05:27:14 INFO - wr::IpcResourceUpdateQueue::ReleaseShmems(this, x.mSmallShmems);
[task 2019-07-12T05:27:14.778Z] 05:27:14 INFO - ^
[task 2019-07-12T05:27:14.778Z] 05:27:14 INFO - /builds/worker/workspace/build/src/gfx/layers/wr/WebRenderBridgeParent.cpp:377:55: note: Please consider using a smart pointer
[task 2019-07-12T05:27:14.778Z] 05:27:14 INFO - In file included from /builds/worker/workspace/build/src/obj-firefox/gfx/layers/Unified_cpp_gfx_layers12.cpp:2:
[task 2019-07-12T05:27:14.778Z] 05:27:14 INFO - In file included from /builds/worker/workspace/build/src/gfx/layers/wr/StackingContextHelper.cpp:7:
[task 2019-07-12T05:27:14.778Z] 05:27:14 INFO - In file included from /builds/worker/workspace/build/src/obj-firefox/dist/include/mozilla/layers/StackingContextHelper.h:12:
[task 2019-07-12T05:27:14.779Z] 05:27:14 INFO - In file included from /builds/worker/workspace/build/src/obj-firefox/dist/include/mozilla/webrender/WebRenderAPI.h:16:
[task 2019-07-12T05:27:14.779Z] 05:27:14 INFO - In file included from /builds/worker/workspace/build/src/obj-firefox/dist/include/mozilla/layers/IpcResourceUpdateQueue.h:10:
[task 2019-07-12T05:27:14.779Z] 05:27:14 INFO - In file included from /builds/worker/workspace/build/src/obj-firefox/ipc/ipdl/_ipdlheaders/mozilla/layers/WebRenderMessages.h:11:
[task 2019-07-12T05:27:14.779Z] 05:27:14 INFO - In file included from /builds/worker/workspace/build/src/obj-firefox/dist/include/ipc/IPCMessageUtils.h:16:
[task 2019-07-12T05:27:14.780Z] 05:27:14 INFO - In file included from /builds/worker/workspace/build/src/obj-firefox/dist/include/mozilla/dom/ipc/StructuredCloneData.h:12:
[task 2019-07-12T05:27:14.780Z] 05:27:14 INFO - In file included from /builds/worker/workspace/build/src/obj-firefox/dist/include/mozilla/dom/StructuredCloneHolder.h:15:
[task 2019-07-12T05:27:14.780Z] 05:27:14 INFO - In file included from /builds/worker/workspace/build/src/obj-firefox/dist/include/mozilla/dom/BindingDeclarations.h:27:

Pushed by abeingessner@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/4689b2870416
Factor out RecvEmptyTransaction's core transaction building r=sotaro
https://hg.mozilla.org/integration/autoland/rev/46c9b479034f
Automatically set content process render root r=kats
Backout by malexandru@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/24d601470a9f
Backed out 2 changesets for causing bustages in nsTArray.h CLOSED TREE

Backed out 2 changesets for causing bustages in nsTArray.h

Backout link: https://hg.mozilla.org/integration/autoland/rev/24d601470a9f44bde93e22cd82a4650614a17b5e

Push with failures: https://treeherder.mozilla.org/#/jobs?repo=autoland&resultStatus=testfailed%2Cbusted%2Cexception%2Cusercancel%2Crunnable&fromchange=46c9b479034f2c6ee710d8d5a703de4a07e77557&tochange=24d601470a9f44bde93e22cd82a4650614a17b5e&selectedJob=256211302

Failure log: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=256210157&repo=autoland&lineNumber=20387

14:47:04 INFO - class MOZ_NON_PARAM MOZ_INHERIT_TYPE_ANNOTATIONS_FROM_TEMPLATE_ARGS Maybe {
14:47:04 INFO - ^
14:47:04 INFO - z:/build/build/src/obj-firefox/dist/include\mozilla/layers/WebRenderScrollData.h(226,49): note: 'mozilla::layers::WebRenderScrollData' is a non-memmove()able type because member 'mScrollIdMap' is a non-memmove()able type 'std::map<ScrollableLayerGuid::ViewID, size_t>' (aka 'map<unsigned long long, unsigned long long>')
14:47:04 INFO - std::map<ScrollableLayerGuid::ViewID, size_t> mScrollIdMap;
14:47:04 INFO - ^
14:47:04 INFO - z:\build\build\src\vs2017_15.8.4\VC\include\map(80,8): note: 'std::map<ScrollableLayerGuid::ViewID, size_t>' (aka 'map<unsigned long long, unsigned long long>') is a non-memmove()able type because it is an stl-provided type not guaranteed to be memmove-able
14:47:04 INFO - class map
14:47:04 INFO - ^
14:47:04 INFO - 1 error generated.
14:47:04 INFO - z:/build/build/src/config/rules.mk:801: recipe for target 'Unified_cpp_gfx_layers12.obj' failed
14:47:04 INFO - mozmake.EXE[4]: *** [Unified_cpp_gfx_layers12.obj] Error 1
14:47:04 INFO - mozmake.EXE[4]: Leaving directory 'z:/build/build/src/obj-firefox/gfx/layers'
14:47:04 INFO - mozmake.EXE[4]: *** Waiting for unfinished jobs....
14:47:04 INFO - mozmake.EXE[4]: Entering directory 'z:/build/build/src/obj-firefox/dom/bindings'
14:47:04 INFO - dom/bindings/RegisterWorkerBindings.obj
14:47:04 INFO - mozmake.EXE[4]: Leaving directory 'z:/build/build/src/obj-firefox/dom/bindings'
14:47:04 INFO - mozmake.EXE[4]: Entering directory 'z:/build/build/src/obj-firefox/gfx/skia'
14:47:04 INFO - z:/build/build/src/sccache/sccache.exe z:/build/build/src/clang/bin/clang.exe --driver-mode=cl -FoSkDebug_win.obj -c -Iz:/build/build/src/obj-firefox/dist/stl_wrappers -DDEBUG=1 -DUNICODE -D_UNICODE -DSKIA_IMPLEMENTATION=1 -DSTATIC_EXPORTABLE_JS_API -DMOZ_HAS_MOZGLUE -DMOZILLA_INTERNAL_API -DIMPL_LIBXUL -Iz:/build/build/src/gfx/skia -Iz:/build/build/src/obj-firefox/gfx/skia -Iz:/build/build/src/gfx/skia/skia/include/c -Iz:/build/build/src/gfx/skia/skia/include/codec -Iz:/build/build/src/gfx/skia/skia/include/config -Iz:/build/build/src/gfx/skia/skia/include/core -Iz:/build/build/src/gfx/skia/skia/include/docs -Iz:/build/build/src/gfx/skia/skia/include/effects -Iz:/build/build/src/gfx/skia/skia/include/encode -Iz:/build/build/src/gfx/skia/skia/include/gpu -Iz:/build/build/src/gfx/skia/skia/include/pathops -Iz:/build/build/src/gfx/skia/skia/include/ports -Iz:/build/build/src/gfx/skia/skia/include/private -Iz:/build/build/src/gfx/skia/skia/include/utils -Iz:/build/build/src/gfx/skia/skia/include/utils/mac -Iz:/build/build/src/gfx/skia/skia/src/codec -Iz:/build/build/src/gfx/skia/skia/src/core -Iz:/build/build/src/gfx/skia/skia/src/image -Iz:/build/build/src/gfx/skia/skia/src/lazy -Iz:/build/build/src/gfx/skia/skia/src/opts -Iz:/build/build/src/gfx/skia/skia/src/sfnt -Iz:/build/build/src/gfx/skia/skia/src/shaders -Iz:/build/build/src/gfx/skia/skia/src/shaders/gradients -Iz:/build/build/src/gfx/skia/skia/src/sksl -Iz:/build/build/src/gfx/skia/skia/src/utils -Iz:/build/build/src/gfx/skia/skia/src/utils/mac -Iz:/build/build/src/gfx/skia/skia/src/utils/win -Iz:/build/build/src/obj-firefox/dist/include -Iz:/build/build/src/obj-firefox/dist/include/nspr -Iz:/build/build/src/obj-firefox/dist/include/nss -MD -FI z:/build/build/src/obj-firefox/mozilla-config.h -DMOZILLA_CLIENT -Qunused-arguments -guard:cf -U_FORTIFY_SOURCE -Xclang -fno-common -Qunused-arguments -fsanitize=address -fsanitize-blacklist=z:/build/build/src/build/sanitizers/asan_blacklist_win.txt -fcrash-diagnostics-dir=z:/build/public/build -fcrash-diagnostics-dir=/z/build/public/build -TP -nologo -Zc:sizedDealloc- -D_HAS_EXCEPTIONS=0 -guard:cf -U_FORTIFY_SOURCE -Xclang -fno-common -W3 -Gy -Zc:inline -Wno-inline-new-delete -Wno-invalid-offsetof -Wno-microsoft-enum-value -Wno-microsoft-include -Wno-unknown-pragmas -Wno-ignored-pragmas -Wno-deprecated-declarations -Wno-invalid-noreturn -Wno-inconsistent-missing-override -Wno-implicit-exception-spec-mismatch -Wno-unused-local-typedef -Wno-ignored-attributes -Wno-used-but-marked-unused -D_SILENCE_TR1_NAMESPACE_DEPRECATION_WARNING -GR- -Z7 -Xclang -load -Xclang z:/build/build/src/obj-firefox/build/clang-plugin/clang-plugin.dll -Xclang -add-plugin -Xclang moz-check -O1 -Oy- -Wno-deprecated-declarations -Wno-overloaded-virtual -Wno-shadow -Wno-sign-compare -Wno-unreachable-code -Wno-unused-function -Wno-implicit-fallthrough -Wno-inconsistent-missing-override -Wno-macro-redefined -Wno-unused-private-field -Xclang -MP -Xclang -dependency-file -Xclang .deps/SkDebug_win.obj.pp -Xclang -MT -Xclang SkDebug_win.obj z:/build/build/src/gfx/skia/skia/src/ports/SkDebug_win.cpp
14:47:04 INFO - mozmake.EXE[4]: Leaving directory 'z:/build/build/src/obj-firefox/gfx/skia'

Attached file Bug 1547351 - BOTOND HELP (obsolete) —
Attachment #9077745 - Attachment is obsolete: true
Flags: needinfo?(a.beingessner)
Pushed by abeingessner@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/6e5d426cd313
Factor out RecvEmptyTransaction's core transaction building r=sotaro
https://hg.mozilla.org/integration/autoland/rev/b594f8e47025
Add support for mozilla::HashMap to ipdl. r=njn
https://hg.mozilla.org/integration/autoland/rev/77ef8e8bc669
Automatically set content process render root r=kats

(working on this...)

Flags: needinfo?(a.beingessner)

the 2/5 wpt8 failure is a bit suspicious here, but I'm hoping it's just getting unlucky on hitting, and not making it distinctly worse, specifically it looks like an instance of Bug 1547719, I think?

Pushed by abeingessner@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/020e9eed3a83
Factor out RecvEmptyTransaction's core transaction building r=sotaro
https://hg.mozilla.org/integration/autoland/rev/f96bd2aae39c
add IsEmpty and fix OrInsert signature for nsBaseHashtable. r=Ehsan
https://hg.mozilla.org/integration/autoland/rev/0c25260c4edf
Automatically set content process render root r=kats

mozregression --launch 020e9eed3a83 --pref gfx.webrender.all:true gfx.webrender.split-render-roots:true -a https://addons.mozilla.org/en-US/firefox/addon/ublock-origin/

Status: RESOLVED → VERIFIED
Duplicate of this bug: 1548688
Attachment #9077799 - Attachment is obsolete: true
Regressions: 1569682
You need to log in before you can comment on or make changes to this bug.