We usually lock `wl_surface`s via `moz_container_wayland_surface_lock` in order to protect us from race conditions. However, `GLContextEGL::SwapBuffers()` also chains up to `wl_surface_commit()`, without being locked. Most of our calls to `moz_container_wayland_surface_lock` happen on the main thread, while WR calls `GLContextEGL::SwapBuffers()` on another thread, so there's a realistic chance to get surface commits while we consider the surface locked, potentially leading to all kinds of crashes. Lets also lock the `wl_surface` when calling `GLContextEGL::SwapBuffers()`.
Bug 1680961 Comment 0 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
We usually lock `wl_surface`s via `moz_container_wayland_surface_lock` in order to protect us from race conditions. However, `GLContextEGL::SwapBuffers()` also chains up to `wl_surface_commit()`, without being locked. Most of our calls to `moz_container_wayland_surface_lock` happen on the main thread, while WR calls `GLContextEGL::SwapBuffers()` on another thread, so there's a realistic chance to get surface commits while we consider the surface locked, potentially causing different kinds of crashes. Lets also lock the `wl_surface` when calling `GLContextEGL::SwapBuffers()`.
We usually lock `wl_surface`s via `moz_container_wayland_surface_lock` in order to protect us from race conditions. However, `GLContextEGL::SwapBuffers()` also chains up to `wl_surface_commit()`, without being locked. Most of our calls to `moz_container_wayland_surface_lock` happen on the main thread, while WR calls `GLContextEGL::SwapBuffers()` on another thread, so there's a realistic chance to get surface commits while we consider the surface locked, potentially causing different kinds of crashes we occasionally see on Wayland with WR. Lets also lock the `wl_surface` when calling `GLContextEGL::SwapBuffers()`.