[Wayland] Use MOZ_ENABLE_WAYLAND to enable wayland backend

RESOLVED FIXED in Firefox 66

Status

()

enhancement
RESOLVED FIXED
7 months ago
19 days ago

People

(Reporter: stransky, Assigned: stransky)

Tracking

(Blocks 1 bug)

Trunk
mozilla67
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox66 fixed, firefox67 fixed)

Details

Attachments

(1 attachment)

Recently we use GDK_BACKEND to enable/disable Wayland backend. That's good for testing but bad for distro deployment.

When GDK_BACKEND is set it's propagated to child processes which may not support wayland thus they fail to run. Also when GDK_BACKEND=wayland is set Firefox fails to start when Wayland backend is not available.

To allow easy deployment let's use a specific MOZ_ENABLE_WAYLAND env which means to use a default available GTK backend (x11 or wayland) and don't fail when Wayland is missing.

Blocks: wayland

Recently we use GDK_BACKEND to enable/disable Wayland backend. That's good for testing but bad for distro deployment.

When GDK_BACKEND is set it's propagated to child processes which may not support wayland thus they fail to run. Also when GDK_BACKEND=wayland is set Firefox fails to start when Wayland backend is not available.

To allow easy deployment let's use a specific MOZ_ENABLE_WAYLAND env which means to use a default available GTK backend (x11 or wayland) and don't fail when Wayland is missing.

Keywords: checkin-needed

Pushed by csabou@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/b9424178ab0b
[Wayland] Use MOZ_ENABLE_WAYLAND to enable wayland backend, r=glandium

Keywords: checkin-needed
Status: NEW → RESOLVED
Closed: 7 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla67

We should get this uplifted for 66.

Flags: needinfo?(stransky)

Comment on attachment 9039042 [details]
Bug 1522780 - [Wayland] Use MOZ_ENABLE_WAYLAND to enable wayland backend, r=glandium

Beta/Release Uplift Approval Request

Feature/Bug causing the regression

none

User impact if declined

Limited use of Firefox Wayland backend for distros.

Is this code covered by automated tests?

No

Has the fix been verified in Nightly?

Yes

Needs manual test from QE?

No

If yes, steps to reproduce

List of other uplifts needed

None

Risk to taking this patch

Low

Why is the change risky/not risky? (and alternatives if risky)

Linux/Gtk+ only, replaces GDK_BACKEND env variable check with a new MOZ_ENABLE_WAYLAND one.

String changes made/needed

Flags: needinfo?(stransky)
Attachment #9039042 - Flags: approval-mozilla-beta?

Comment on attachment 9039042 [details]
Bug 1522780 - [Wayland] Use MOZ_ENABLE_WAYLAND to enable wayland backend, r=glandium

Fix to help smooth the way for distros, should only affect Linux
OK to uplift for beta 4.

Attachment #9039042 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Duplicate of this bug: 1508803

This segfaults during startup on FreeBSD 12-STABLE (r350321) as well as on CURRENT. Tested on sway and an experimental wayland version of hikari. Should I turn this into a new issue?

(lldb) target create "/usr/local/bin/firefox"
Current executable set to '/usr/local/bin/firefox' (x86_64).
(lldb) run
Process 29301 launching
Process 29301 launched: '/usr/local/bin/firefox' (x86_64)
Process 29301 stopped
* thread #19, name = 'Compositor', stop reason = signal SIGSEGV: invalid address (fault address: 0x0)
    frame #0: 0x000000080778588b libxul.so`mozilla::widget::WaylandShmPool::CreateTemporaryFile(int) + 251
libxul.so`mozilla::widget::WaylandShmPool::CreateTemporaryFile:
->  0x80778588b <+251>: movl   $0xbb, 0x0
    0x807785896 <+262>: callq  0x80997bd20               ; symbol stub for: abort
    0x80778589b <+267>: leaq   -0x58(%rbp), %rdi
    0x80778589f <+271>: callq  0x805124840               ; nsTSubstring<char>::Finalize()
(lldb) bt
* thread #19, name = 'Compositor', stop reason = signal SIGSEGV: invalid address (fault address: 0x0)
  * frame #0: 0x000000080778588b libxul.so`mozilla::widget::WaylandShmPool::CreateTemporaryFile(int) + 251
    frame #1: 0x0000000807785937 libxul.so`mozilla::widget::WaylandShmPool::WaylandShmPool(mozilla::widget::nsWaylandDisplay*, int) + 23
    frame #2: 0x00000008077864ad libxul.so`mozilla::widget::WindowSurfaceWayland::GetWaylandBufferToDraw(int, int) + 205
    frame #3: 0x0000000807786a73 libxul.so`mozilla::widget::WindowSurfaceWayland::Lock(mozilla::gfx::IntRegionTyped<mozilla::LayoutDevicePixel> const&) + 275
    frame #4: 0x0000000807775cfb libxul.so`mozilla::widget::WindowSurfaceProvider::StartRemoteDrawingInRegion(mozilla::gfx::IntRegionTyped<mozilla::LayoutDevicePixel>&, mozilla::layers::BufferMode*) + 155
    frame #5: 0x0000000805e27c13 libxul.so`mozilla::layers::BasicCompositor::BeginFrame(mozilla::gfx::IntRegionTyped<mozilla::gfx::UnknownUnits> const&, mozilla::gfx::IntRectTyped<mozilla::gfx::UnknownUnits> const*, mozilla::gfx::IntRectTyped<mozilla::gfx::UnknownUnits> const&, mozilla::gfx::IntRegionTyped<mozilla::gfx::UnknownUnits> const&, mozilla::gfx::IntRectTyped<mozilla::gfx::UnknownUnits>*, mozilla::gfx::IntRectTyped<mozilla::gfx::UnknownUnits>*) + 1891
    frame #6: 0x0000000805e80067 libxul.so`mozilla::layers::LayerManagerComposite::Render(mozilla::gfx::IntRegionTyped<mozilla::gfx::UnknownUnits> const&, mozilla::gfx::IntRegionTyped<mozilla::gfx::UnknownUnits> const&) + 663
    frame #7: 0x0000000805e7f8f6 libxul.so`mozilla::layers::LayerManagerComposite::UpdateAndRender() + 2246
    frame #8: 0x0000000805e7ef58 libxul.so`mozilla::layers::LayerManagerComposite::EndTransaction(mozilla::TimeStamp const&, mozilla::layers::LayerManager::EndTransactionFlags) + 184
    frame #9: 0x0000000805e99f49 libxul.so`mozilla::layers::CompositorBridgeParent::CompositeToTarget(mozilla::layers::BaseTransactionId<mozilla::VsyncIdType>, mozilla::gfx::DrawTarget*, mozilla::gfx::IntRectTyped<mozilla::gfx::UnknownUnits> const*) + 1257
    frame #10: 0x0000000805ea42bf libxul.so`mozilla::layers::CompositorVsyncScheduler::Composite(mozilla::layers::BaseTransactionId<mozilla::VsyncIdType>, mozilla::TimeStamp) + 127
    frame #11: 0x0000000805eb8dcf libxul.so`mozilla::detail::RunnableMethodImpl<mozilla::layers::CompositorVsyncScheduler*, void (mozilla::layers::CompositorVsyncScheduler::*)(mozilla::layers::BaseTransactionId<mozilla::VsyncIdType>, mozilla::TimeStamp), true, (mozilla::RunnableKind)1, mozilla::layers::BaseTransactionId<mozilla::VsyncIdType>, mozilla::TimeStamp>::Run() + 47
    frame #12: 0x000000080558e5c7 libxul.so`MessageLoop::DoWork() + 727
    frame #13: 0x000000080558ef71 libxul.so`base::MessagePumpDefault::Run(base::MessagePump::Delegate*) + 433
    frame #14: 0x000000080558dba8 libxul.so`MessageLoop::Run() + 88
    frame #15: 0x00000008055a566e libxul.so`base::Thread::ThreadMain() + 462
    frame #16: 0x0000000805594cda libxul.so`ThreadFunc(void*) + 10
    frame #17: 0x00000008011ed75b libthr.so.3`thread_start(curthread=0x0000000812da4000) at thr_create.c:292:16
You need to log in before you can comment on or make changes to this bug.