Screen sharing preview only works once.

RESOLVED FIXED in Firefox 69

Status

()

defect
RESOLVED FIXED
3 months ago
Last month

People

(Reporter: jib, Assigned: sotaro, NeedInfo)

Tracking

(Regression, {regression})

Trunk
mozilla69
Points:
---
Dependency tree / graph

Firefox Tracking Flags

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

Details

Attachments

(2 attachments)

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.

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

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

Debian Testing, KDE, X11
Confirmed.

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\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

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 sikeda@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/99f335f3f06b
Handle non-webrender widget case during enabling WebRender at ImageBridge r=nical
Status: NEW → RESOLVED
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.