1522780 - [Wayland] Use MOZ_ENABLE_WAYLAND to enable wayland backend

Status: RESOLVED FIXED

(Toolkit :: Startup and Profile System, enhancement)

Description

[Martin Stránský [:stransky] (ni? me)]

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.

Comment 1

[Martin Stránský [:stransky] (ni? me)]

Attachment: Bug 1522780 - [Wayland] Use MOZ_ENABLE_WAYLAND to enable wayland backend, r=glandium

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.

Comment 2

[Martin Stránský [:stransky] (ni? me)]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=a548fd5786d4091d92b68668bfb2e8431a0f1725

Comment 3

[Pulsebot]

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

Comment 4

[Stefan Hindli [:stefan_hindli]]

https://hg.mozilla.org/mozilla-central/rev/b9424178ab0b

Comment 5

[Mike Hommey [:glandium]]

We should get this uplifted for 66.

Comment 6

[Martin Stránský [:stransky] (ni? me)]

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

Comment 7

[Liz Henry (:lizzard) (relman/hg->git project)]

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.

Comment 8

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

https://hg.mozilla.org/releases/mozilla-beta/rev/72201a8d9d95

Comment 10

[raichoo]

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

Comment 11

[Sawyer Bergeron]

Attachment: Bug 1522780 - Allow using "falsy" values for MOZ_ENABLE_WAYLAND

Comment 12

[Phabricator Automation]

Comment on attachment 9197598 [details]
Bug 1522780 - Allow using "falsy" values for MOZ_ENABLE_WAYLAND

Revision D102095 was moved to bug 1588129. Setting attachment 9197598 [details] to obsolete.