[Wayland] gfx.webrender.all on Wayland displays an empty window with GDK_BACKEND=wayland

RESOLVED FIXED in Firefox 67

Status

()

P3
normal
RESOLVED FIXED
3 months ago
11 days ago

People

(Reporter: kubrick, Assigned: sotaro)

Tracking

(Blocks: 2 bugs)

Trunk
mozilla67
Unspecified
Linux
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox66 wontfix, firefox67 fixed)

Details

Attachments

(5 attachments, 6 obsolete attachments)

472.86 KB, image/png
Details
602.69 KB, image/png
Details
658.31 KB, image/png
Details
47 bytes, text/x-phabricator-request
sotaro
: review+
Details | Review
47 bytes, text/x-phabricator-request
Details | Review
(Reporter)

Description

3 months ago
With build id 20181213224257 on Linux 4.19.9, intel graphics, Gnome 3.30.2.

Webrender works very well on XWayland but not on the native Wayland build (launched with GDK_BACKEND=wayland).

Setting layers.acceleration.force-enabled to true works well, OpenGL rendering is enabled and smooth but gfx.webrender.all (alone or in combination) result on a transparent / empty window to be drawn.
Funny enough, the controls still work, I can see the cursor changing shape when hovering the address bar for example and other overlays are drawn correctly (see attachement).
(Reporter)

Comment 1

3 months ago
Interestingly, it seems like the first launch after an update is always successful, but all subsequent launches result in empty windows.

Comment 2

3 months ago
(In reply to Francois Guerraz from comment #1)
> Interestingly, it seems like the first launch after an update is always
> successful, but all subsequent launches result in empty windows.

Sounds possibly related to shader caching, as I think we invalidate it during updates?

Linux or Wayland isn't in our MVP, so marking this P3.
Priority: -- → P3
I think it's a duplicate of Bug 1485616 - can you please check latest nightly?
Flags: needinfo?(kubrick)

Comment 4

3 months ago
I also see this quite exactly as described (flatpak nightly from today, 17.12.).
And I can also confirm that under rare circumstances things work fine

fedora 29, intel skylake, gnome git-master
Flatpak may carry other issues so it's better to test directly Mozilla binaries. You just need to download the tarball and run as "GDB_BACKEND=wayland ./firefox".
(In reply to Martin Stránský [:stransky] from comment #5)
> Flatpak may carry other issues so it's better to test directly Mozilla
> binaries. You just need to download the tarball and run as
> "GDB_BACKEND=wayland ./firefox".

Sorry, I mean GDK_BACKEND=wayland of course :)
Yes, I can see that with gfx.webrender.all=true now. It's more reproducible on optimized builds, I used debug builds which almost work.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(kubrick)
Summary: [Wayland] Webrender on Wayland displays an empty window → [Wayland] gfx.webrender.all on Wayland displays an empty window
I see "Initializing context 0x7f803c98ecf0 surface (nil) on display 0x7f8044a94800" which can be the problem here.
Blocks: 1491303
Component: Graphics → Graphics: WebRender
[Parent 2716, Main Thread] WARNING: nsWindow::GetNativeData(): NS_NATIVE_SHAREABLE_WINDOW is not handled on Wayland!: file /home/komat/tmp676-trunk-gtk3/src-wayland/widget/gtk/nsWindow.cpp, line 1561

Can be also related.
This is really a variant of Bug 1485616 where we wait until mozcontainer is mapped and mContainer->ready_to_draw flag is set. I don't know if that's possible at WebRender to wait until we have complete widget to draw into. A variant may be to create a dummy wl_surface/wl_egl_window if it's even possible.
The check at widget level code is performed here:

https://dxr.mozilla.org/mozilla-central/rev/c2593a3058afdfeaac5c990e18794ee8257afe99/widget/gtk/nsWindow.cpp#2111

we need something similar to check before we create EGL GLContext for the nsWindow.

Updated

3 months ago
Attachment #9032040 - Attachment description: Firefox on Wayland - almost nothing visible except for the webpage suggestions → Firefox on Wayland with gfx.webrender.all=true - almost nothing visible except for the webpage suggestions
Sotaro, is it possible to postpone WebRender rendering / GlContext creation until we have fully mapped widget to draw into?
Flags: needinfo?(sotaro.ikeda.g)
(Assignee)

Comment 15

3 months ago
(In reply to Martin Stránský [:stransky] from comment #14)
> Sotaro, is it possible to postpone WebRender rendering / GlContext creation
> until we have fully mapped widget to draw into?

Hmm it seems not easy to postopone GLContext creation. But it seems possible to postpone EGLSurface creation like RenderCompositorANGLE. RenderCompositorANGLE create GLContext by GLContextProviderEGL::CreateHeadless() in CreateGLContextANGLE() and EGLSurface is created later separately in RenderCompositorANGLE::ResizeBufferIfNeeded().
Flags: needinfo?(sotaro.ikeda.g)
I think that bug 1507770 is a duplicate, I could reproduce it reliably by booting with the parameter "maxcpus=1". Please confirm.
Correction: I could *not* reproduce it reliably by booting with the parameter "maxcpus=1".
(Reporter)

Comment 18

3 months ago
In my case the bug is reproducible all the same whether I boot with maxcpus=1 or launch firefox with "taskset 0x1".
(Assignee)

Comment 19

3 months ago
(In reply to Sotaro Ikeda [:sotaro out of office 28/Dec - 3/Jan] from comment #15)
> (In reply to Martin Stránský [:stransky] from comment #14)
> > Sotaro, is it possible to postpone WebRender rendering / GlContext creation
> > until we have fully mapped widget to draw into?
> 
> Hmm it seems not easy to postopone GLContext creation. But it seems possible
> to postpone EGLSurface creation like RenderCompositorANGLE.
> RenderCompositorANGLE create GLContext by
> GLContextProviderEGL::CreateHeadless() in CreateGLContextANGLE() and
> EGLSurface is created later separately in
> RenderCompositorANGLE::ResizeBufferIfNeeded().

I checked that EGLSurface was not created by GLContextEGL.
(Assignee)

Comment 21

3 months ago
attachment 9033237 [details] [diff] [review] is still wip patch, but it address the problem for me, though GLContextProviderEGL::CreateHeadless() did not work.
(Reporter)

Comment 22

3 months ago
I would have loved to try the patch but it doesn't apply cleanly on master and doesn't compile if I try to resolve the conflicts
(Assignee)

Comment 23

3 months ago
Bebased. I confirmed the build locally with latest m-c.
(Assignee)

Updated

3 months ago
Attachment #9033237 - Attachment is obsolete: true
(Reporter)

Comment 24

3 months ago
Comment on attachment 9034351 [details] [diff] [review]
wip patch - Add RenderCompositorEGL for wayland

Review of attachment 9034351 [details] [diff] [review]:
-----------------------------------------------------------------

Works for me.
(Assignee)

Comment 25

3 months ago

Thanks for the confirmation!

(Assignee)

Updated

2 months ago
Assignee: nobody → sotaro.ikeda.g

Comment 26

2 months ago
Comment on attachment 9034351 [details] [diff] [review]
wip patch - Add RenderCompositorEGL for wayland

Review of attachment 9034351 [details] [diff] [review]:
-----------------------------------------------------------------

Breaks build if gtk3 was built with --disable-wayland-backend i.e., the only way to disable Wayland support at build-time after bug 1501218.

In file included from objdir/widget/gtk/Unified_cpp_widget_gtk0.cpp:11:
widget/gtk/CompositorWidgetParent.cpp:45:3: error: use of undeclared identifier
      'RequestsUpdatingEGLSurface'; did you mean 'RecvRequestsUpdatingEGLSurface'?
  RequestsUpdatingEGLSurface();
  ^~~~~~~~~~~~~~~~~~~~~~~~~~
  RecvRequestsUpdatingEGLSurface
widget/gtk/CompositorWidgetParent.cpp:43:49: note: 'RecvRequestsUpdatingEGLSurface' declared here
mozilla::ipc::IPCResult CompositorWidgetParent::RecvRequestsUpdatingEGLSurface()
                                                ^
In file included from objdir/widget/gtk/Unified_cpp_widget_gtk0.cpp:2:
In file included from widget/gtk/CompositorWidgetChild.cpp:6:
In file included from widget/gtk/CompositorWidgetChild.h:9:
widget/gtk/GtkCompositorWidget.h:78:8: error: private field 'mWaylandRequestsUpdatingEGLSurface' is
      not used [-Werror,-Wunused-private-field]
  bool mWaylandRequestsUpdatingEGLSurface;
       ^
2 errors generated.

::: gfx/webrender_bindings/RenderCompositor.cpp
@@ +30,5 @@
>      return RenderCompositorANGLE::Create(std::move(aWidget));
>    }
>  #endif
> +
> +#ifdef MOZ_WIDGET_GTK

Did you mean #ifdef MOZ_WAYLAND instead?

Comment 27

2 months ago

Also there's a crashing bug here, it tries to get_wl_egl_window when it shouldn't (?). Happens when e.g. opening webextension popovers, but I think I've seen it with ordinary windows too.

* thread #1, name = 'Renderer', stop reason = signal SIGSEGV
  * frame #0: 0x00000008013b99ca libc.so.7`__sys_thr_kill at thr_kill.S:3
    frame #1: 0x00000008013b9364 libc.so.7`__raise(s=11) at raise.c:52:10
    frame #2: 0x0000000807efff42 libxul.so`nsProfileLock::FatalSignalHandler(signo=11, info=0x00007fffde630330, context=<unavailable>) at nsProfileLock.cpp:165:7
    frame #3: 0x000000080864ba51 libxul.so`WasmTrapHandler(signum=11, info=0x00007fffde630330, context=0x00007fffde62ffc0) at WasmSignalHandlers.cpp:928:5
    frame #4: 0x00000008011e643e libthr.so.3`handle_signal(actp=0x00007fffde62ff40, sig=11, info=0x00007fffde630330, ucp=0x00007fffde62ffc0) at thr_sig.c:246:3
    frame #5: 0x00000008011e59f2 libthr.so.3`thr_sighandler(sig=11, info=0x00007fffde630330, _ucp=0x00007fffde62ffc0) at thr_sig.c:191:2
    frame #6: 0x00007fffffffe003
    frame #7: 0x00000008070547f3 libxul.so`moz_container_get_wl_surface(container=<unavailable>) at mozcontainer.cpp:509:40
    frame #8: 0x00000008070549ff libxul.so`moz_container_get_wl_egl_window(container=0x000000080e099d10) at mozcontainer.cpp:539:27
    frame #9: 0x00000008070309a9 libxul.so`nsWindow::GetNativeData(this=<unavailable>, aDataType=<unavailable>) at nsWindow.cpp:1587:30
    frame #10: 0x0000000805a3fa09 libxul.so`mozilla::gl::GLContextEGL::CreateEGLSurfaceForCompositorWidget(aCompositorWidget=0x0000000824a74fc0, aForceAccelerated=<unavailable>) at GLContextProviderEGL.cpp:310:32
    frame #11: 0x0000000805c97c9c libxul.so`mozilla::wr::RenderCompositorEGL::CreateEGLSurface(aWidget=<unavailable>) at RenderCompositorEGL.cpp:64:13
    frame #12: 0x0000000805c97f89 libxul.so`mozilla::wr::RenderCompositorEGL::BeginFrame(this=0x000000081f3c0b90) at RenderCompositorEGL.cpp:85:21
    frame #13: 0x0000000805c9e0d1 libxul.so`mozilla::wr::RendererOGL::UpdateAndRender(this=0x0000000829a00080, aReadbackSize=0x00007fffde630ca0, aReadbackBuffer=0x00007fffde630c88, aHadSlowFrame=false, aOutStats=0x00007fffde630b80) at RendererOGL.cpp:113:21
    frame #14: 0x0000000805c9d8a9 libxul.so`mozilla::wr::RenderThread::UpdateAndRender(this=<unavailable>, aWindowId=<unavailable>, aStartId=0x00007fffde630c78, aStartTime=0x00007fffde630c80, aRender=<unavailable>, aReadbackSize=0x00007fffde630ca0, aReadbackBuffer=0x00007fffde630c88, aHadSlowFrame=<unavailable>) at RenderThread.cpp:369:26
    frame #15: 0x0000000805c9d730 libxul.so`mozilla::wr::RenderThread::HandleFrame(this=<unavailable>, aWindowId=<unavailable>, aRender=true) at RenderThread.cpp:262:3
    frame #16: 0x0000000805ca509f libxul.so`mozilla::detail::RunnableMethodImpl<mozilla::wr::RenderThread*, void (mozilla::wr::RenderThread::*)(mozilla::wr::WrWindowId, bool), true, (mozilla::RunnableKind)0, mozilla::wr::WrWindowId, bool>::Run() [inlined] decltype(o=<unavailable>, m=<unavailable>, args=<unavailable>).*fp0(Get<0ul>(fp1).PassAsParameter(), Get<1ul>(fp1).PassAsParameter())) mozilla::detail::RunnableMethodArguments<mozilla::wr::WrWindowId, bool>::applyImpl<mozilla::wr::RenderThread, void (mozilla::wr::RenderThread::*)(mozilla::wr::WrWindowId, bool), StoreCopyPassByConstLRef<mozilla::wr::WrWindowId>, StoreCopyPassByConstLRef<bool>, 0ul, 1ul>(mozilla::wr::RenderThread*, void (mozilla::wr::RenderThread::*)(mozilla::wr::WrWindowId, bool), mozilla::Tuple<StoreCopyPassByConstLRef<mozilla::wr::WrWindowId>, StoreCopyPassByConstLRef<bool> >&, std::__1::integer_sequence<unsigned long, 0ul, 1ul>) at nsThreadUtils.h:1119:12
    frame #17: 0x0000000805ca5080 libxul.so`mozilla::detail::RunnableMethodImpl<mozilla::wr::RenderThread*, void (mozilla::wr::RenderThread::*)(mozilla::wr::WrWindowId, bool), true, (mozilla::RunnableKind)0, mozilla::wr::WrWindowId, bool>::Run() [inlined] _ZN7mozilla6detail23RunnableMethodArgumentsIJNS_2wr10WrWindowIdEbEE5applyINS2_12RenderThreadEMS6_FvS3_bEEEDTcl9applyImplfp_fp0_dtdefpT10mArgumentstlNSt3__116integer_sequenceImJLm0ELm1EEEEEEEPT_T0_(this=<unavailable>, o=<unavailable>, m=<unavailable>) at nsThreadUtils.h:1125
    frame #18: 0x0000000805ca5080 libxul.so`mozilla::detail::RunnableMethodImpl<mozilla::wr::RenderThread*, void (mozilla::wr::RenderThread::*)(mozilla::wr::WrWindowId, bool), true, (mozilla::RunnableKind)0, mozilla::wr::WrWindowId, bool>::Run(this=<unavailable>) at nsThreadUtils.h:1171
(Assignee)

Comment 28

2 months ago

(In reply to greg from comment #27)

Also there's a crashing bug here, it tries to get_wl_egl_window when it shouldn't (?). Happens when e.g. opening webextension popovers, but I think I've seen it with ordinary windows too.

Thanks for the report! I created Bug 1525213 for it.

(Assignee)

Comment 29

2 months ago

(In reply to Jan Beich from comment #26)

Comment on attachment 9034351 [details] [diff] [review]
wip patch - Add RenderCompositorEGL for wayland

Review of attachment 9034351 [details] [diff] [review]:

Breaks build if gtk3 was built with --disable-wayland-backend i.e., the only
way to disable Wayland support at build-time after bug 1501218.

::: gfx/webrender_bindings/RenderCompositor.cpp
@@ +30,5 @@

 return RenderCompositorANGLE::Create(std::move(aWidget));

}
#endif
+
+#ifdef MOZ_WIDGET_GTK

Did you mean #ifdef MOZ_WAYLAND instead?

Yes.

Thank you for the notification.

(Assignee)

Comment 30

2 months ago

Fixed build failure during disabling wayland.

Attachment #9034351 - Attachment is obsolete: true
(Assignee)

Comment 31

2 months ago
Attachment #9041385 - Attachment is obsolete: true
Attachment #9041394 - Attachment description: Bug 1514156 - Add GLContextEGL::CreateEGLSurfaceForCompositorWidget() → Bug 1514156 - Add GLContextEGL::CreateEGLSurfaceForCompositorWidget() for Wayland
(Assignee)

Comment 33

2 months ago

When GDK_BACKEND is wayland, widget is not fully mapped during creating CompositorSession. During CompositorSession creation, GLContextProviderEGL::CreateForCompositorWidget() creates GLContextEGL, but we could not create valid EGLSurface. We could create valid EGLSurface when widget is fully mapped. CreateEGLSurfaceForCompositorWidget() is used for creating valid EGLSurface after widget is fully mapped.

https://phabricator.services.mozilla.com/D18654

Attachment #9041397 - Attachment is obsolete: true
(Assignee)

Updated

2 months ago
Attachment #9041394 - Flags: review+
(Assignee)

Comment 34

2 months ago
Attachment #9041387 - Attachment is obsolete: true
(Assignee)

Updated

2 months ago
Attachment #9041654 - Attachment is obsolete: true

Comment 36

a month ago
Pushed by sikeda@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/d97a89ada9e6
Add GLContextEGL::CreateEGLSurfaceForCompositorWidget() for Wayland r=jgilbert
https://hg.mozilla.org/integration/mozilla-inbound/rev/19ccde31eaaa
Add RenderCompositorEGL for wayland r=nical

Comment 37

a month ago
bugherder
Status: NEW → RESOLVED
Last Resolved: a month ago
status-firefox67: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla67
Depends on: 1527556
(Reporter)

Comment 38

a month ago

I don't think this is completely fixed, extensions/addons surfaces are still transparent (tried µBlock0, bitwarden & feedbro).

Updated

a month ago
Duplicate of this bug: 1507770
(Assignee)

Comment 40

a month ago

(In reply to Francois Guerraz from comment #38)

I don't think this is completely fixed, extensions/addons surfaces are still transparent (tried µBlock0, bitwarden & feedbro).

Created Bug 1527804 for it.

(Assignee)

Updated

a month ago
Depends on: 1527804
(Assignee)

Updated

a month ago
Summary: [Wayland] gfx.webrender.all on Wayland displays an empty window → [Wayland] gfx.webrender.all on Wayland displays an empty window with GDK_BACKEND=wayland

I think this may be best to let ride with 67.

status-firefox66: affected → wontfix

Comment 42

24 days ago

This still happens for me on about 30% of runs (Gnome Wayland, WebRender, session restore). A window is created, but it's transparent or otherwise invisible.

Comment 43

24 days ago

Never mind, that could be bug 1532024.

You need to log in before you can comment on or make changes to this bug.