1557105 - Screen sharing preview only works once.

Status: RESOLVED FIXED

(Core :: Graphics: WebRender, defect)

Description

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

Attachment: ScreensharingPreviewBug3.mp4

STRs

1. On FF in Windows 10, open https://mozilla.github.io/webrtc-landing/gum_test.html
2. Click "Screen"
3. In permission popup, pick "Entire screen"
4. Observe preview.
5. Hit Allow.
6. Refresh page and repeat steps 1-4

Expected result: Preview shows the second time as wel
Actual result: Preview shows the first time, but is blank the second and all subsequent times.

Comment 1

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

2019-06-05T14:31:42: INFO : Narrowed inbound regression window from [71f86120, f1da54a2] (3 builds) to [e03c9835, f1da54a2] (2 builds) (~1 steps left)
2019-06-05T14:31:42: DEBUG : Starting merge handling...
2019-06-05T14:31:42: DEBUG : Using url: https://hg.mozilla.org/integration/autoland/json-pushes?changeset=f1da54a2d166d6370d485d2b3d2f5b386a6af177&full=1
2019-06-05T14:31:43: DEBUG : Found commit message:
Bug 1490742. Enable gfx.webrender.qualified.all on Nightly r=Gankro

Differential Revision: https://phabricator.services.mozilla.com/D5701

2019-06-05T14:31:43: DEBUG : Did not find a branch, checking all integration branches
2019-06-05T14:31:43: INFO : The bisection is done.
2019-06-05T14:31:43: INFO : Stopped

Comment 2

[Darkspirit]

Debian Testing, KDE, X11
Confirmed.

Comment 3

[Kartikaya Gupta (email:[e-mail])]

I can repro this easily on Windows. In a debug build I get this assertion failure and process crash which is likely the root cause:

Assertion failure: !aCompositable->AsWebRenderImageHost(), at c:/Users/kats/zspace/gecko-misc/gfx/layers/ipc/LayerTransactionParent.cpp:843
#01: mozilla::layers::PLayerTransactionParent::OnMessageReceived (c:\Users\kats\zspace\gecko-misc\obj-x86_64-pc-mingw32\ipc\ipdl\PLayerTransactionParent.cpp:125)
#02: mozilla::layers::PCompositorManagerParent::OnMessageReceived (c:\Users\kats\zspace\gecko-misc\obj-x86_64-pc-mingw32\ipc\ipdl\PCompositorManagerParent.cpp:200)
#03: mozilla::ipc::MessageChannel::DispatchAsyncMessage (c:\Users\kats\zspace\gecko-misc\ipc\glue\MessageChannel.cpp:2159)
#04: mozilla::ipc::MessageChannel::DispatchMessage (c:\Users\kats\zspace\gecko-misc\ipc\glue\MessageChannel.cpp:2082)
#05: mozilla::ipc::MessageChannel::RunMessage (c:\Users\kats\zspace\gecko-misc\ipc\glue\MessageChannel.cpp:1940)
#06: mozilla::ipc::MessageChannel::MessageTask::Run (c:\Users\kats\zspace\gecko-misc\ipc\glue\MessageChannel.cpp:1972)
#07: MessageLoop::RunTask (c:\Users\kats\zspace\gecko-misc\ipc\chromium\src\base\message_loop.cc:443)
#08: MessageLoop::DeferOrRunPendingTask (c:\Users\kats\zspace\gecko-misc\ipc\chromium\src\base\message_loop.cc:450)
#09: MessageLoop::DoWork (c:\Users\kats\zspace\gecko-misc\ipc\chromium\src\base\message_loop.cc:523)
#10: base::MessagePumpForUI::DoRunLoop (c:\Users\kats\zspace\gecko-misc\ipc\chromium\src\base\message_pump_win.cc:204)
#11: base::MessagePumpWin::Run (c:\Users\kats\zspace\gecko-misc\ipc\chromium\src\base\message_pump_win.h:79)
#12: MessageLoop::RunHandler (c:\Users\kats\zspace\gecko-misc\ipc\chromium\src\base\message_loop.cc:309)
#13: base::Thread::ThreadMain (c:\Users\kats\zspace\gecko-misc\ipc\chromium\src\base\thread.cc:192)
#14: `anonymous namespace'::ThreadFunc (c:\Users\kats\zspace\gecko-misc\ipc\chromium\src\base\platform_thread_win.cc:20)
#15: BaseThreadInitThunk[C:\WINDOWS\System32\KERNEL32.DLL +0x17974]
#16: patched_BaseThreadInitThunk (c:\Users\kats\zspace\gecko-misc\mozglue\build\WindowsDllBlocklist.cpp:701)
#17: RtlUserThreadStart[C:\WINDOWS\SYSTEM32\ntdll.dll +0x6a271]

This seems to be the same as bug 1553579

Comment 4

[Kartikaya Gupta (email:[e-mail])]

:aosmond or :sotaro, do you know what might be happening here? It seems like we do have some widgets that are running without WR but they are sharing compositables with WR-enabled widgets and this can trigger the assertion failure?

Comment 5

[Kartikaya Gupta (email:[e-mail])]

Also sounds related to bug 1557251

Comment 6

[Sotaro Ikeda [:sotaro]]

I take a look.

Comment 7

[Sotaro Ikeda [:sotaro]]

Problem was related to Bug 1557251 . But it was a bit complex than just video playback. During WebRTC, 2 ImageContainers were created. One was for creating Image(TextureClient), another was for rendering to video tag.

Comment 8

[Sotaro Ikeda [:sotaro]]

Attachment: Bug 1557105 - Handle non-webrender widget case during enabling WebRender at ImageBridge

Comment 9

[Sotaro Ikeda [:sotaro]]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=a9e2a6de2cc94fdce032a05f51b0c86ec3e5c9f8

Comment 10

[Sotaro Ikeda [:sotaro]]

Attachment 9070531 [details] address the problem for me.

Comment 11

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/99f335f3f06b
Handle non-webrender widget case during enabling WebRender at ImageBridge r=nical

Comment 12

[Noemi Erli[:noemi_erli]]

https://hg.mozilla.org/mozilla-central/rev/99f335f3f06b

Comment 13

[Ryan VanderMeulen [:RyanVM]]

I assume this fix can ride the trains since WR is on a staged rollout, but feel free to nominate this for Beta approval if you feel strongly that we should take it for 68.