Screen sharing preview only works once.

RESOLVED FIXED in Firefox 69



3 months ago
Last month


(Reporter: jib, Assigned: sotaro, NeedInfo)


(Regression, {regression})

Dependency tree / graph

Firefox Tracking Flags

(firefox-esr60 unaffected, firefox67 wontfix, firefox67.0.1 wontfix, firefox68 wontfix, firefox69 fixed)



(2 attachments)


  1. On FF in Windows 10, open
  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.

No longer blocks: 1517030
No longer depends on: 1539938, 1511416

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:
2019-06-05T14:31:43: DEBUG : Found commit message:
Bug 1490742. Enable gfx.webrender.qualified.all on Nightly r=Gankro

Differential Revision:

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

Blocks: 1490742
Keywords: regression
OS: All → Windows 10
No longer blocks: 1490742
Regressed by: 1490742

Debian Testing, KDE, X11

Mentor: jhofmann
Component: Device Permissions → Graphics: WebRender
OS: Windows 10 → All
Priority: P2 → --
Product: Firefox → Core
Summary: Screen sharing preview on Windows 10 only works once. → Screen sharing preview only works once.

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\
#08: MessageLoop::DeferOrRunPendingTask (c:\Users\kats\zspace\gecko-misc\ipc\chromium\src\base\
#09: MessageLoop::DoWork (c:\Users\kats\zspace\gecko-misc\ipc\chromium\src\base\
#10: base::MessagePumpForUI::DoRunLoop (c:\Users\kats\zspace\gecko-misc\ipc\chromium\src\base\
#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\
#13: base::Thread::ThreadMain (c:\Users\kats\zspace\gecko-misc\ipc\chromium\src\base\
#14: `anonymous namespace'::ThreadFunc (c:\Users\kats\zspace\gecko-misc\ipc\chromium\src\base\
#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

See Also: → 1553579

: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?

Flags: needinfo?(sotaro.ikeda.g)
Flags: needinfo?(aosmond)

I take a look.

Assignee: nobody → sotaro.ikeda.g
Blocks: 1553969
Flags: needinfo?(sotaro.ikeda.g)

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.

Attachment 9070531 [details] address the problem for me.

Pushed by
Handle non-webrender widget case during enabling WebRender at ImageBridge r=nical
Closed: 2 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla69

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.

Duplicate of this bug: 1557251
No longer regressed by: 1559318
Regressions: 1559318
QA Whiteboard: [qa-69b-p2]
You need to log in before you can comment on or make changes to this bug.