Firefox crashes on Wayland with Explicit Sync on Nvidia
Categories
(Core :: Widget: Gtk, defect, P1)
Tracking
()
People
(Reporter: Vash63, Assigned: stransky)
References
(Blocks 3 open bugs)
Details
(Keywords: crash, topcrash-thunderbird, wayland)
Attachments
(7 files)
48 bytes,
text/x-phabricator-request
|
RyanVM
:
approval-mozilla-esr128+
|
Details | Review |
48 bytes,
text/x-phabricator-request
|
RyanVM
:
approval-mozilla-esr128+
|
Details | Review |
48 bytes,
text/x-phabricator-request
|
RyanVM
:
approval-mozilla-esr128+
|
Details | Review |
16.33 KB,
text/plain
|
Details | |
16.33 KB,
text/plain
|
Details | |
16.33 KB,
text/plain
|
Details | |
50.06 KB,
text/plain
|
Details |
User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/125.0.0.0 Safari/537.36
Steps to reproduce:
- Installed the new Nvidia 555 series drivers
- Used Gnome 46.1 or another compositor with Explicit Sync support (kwin w/ some patches)
- Run Firefox
Actual results:
Firefox crashes with:
$ firefox-nightly/firefox
[GFX1-]: Wayland protocol error: wp_linux_drm_syncobj_surface_v1@59: error 4: No Acquire point provided
ExceptionHandler::WaitForContinueSignal waiting for continue signal...
ExceptionHandler::GenerateDump cloned child 43927
ExceptionHandler::SendContinueSignalToChild sent continue signal to child
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.
Expected results:
Firefox runs
Comment 1•8 months ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::Widget: Gtk' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.
For me, the error message looks slightly different:
$ firefox
[GFX1-]: Wayland protocol error: wp_linux_drm_syncobj_surface_v1@75: error 4: explicit sync is used, but no acquire point is set
ExceptionHandler::GenerateDump cloned child 118029
ExceptionHandler::WaitForContinueSignal waiting for continue signal...
ExceptionHandler::SendContinueSignalToChild sent continue signal to child
Exiting due to channel error.
However, I think it is the same error.
Troubleshoot mode works fine, normal mode (also without addons) crashes
Updated•8 months ago
|
Saw this when discussing this online: https://invent.kde.org/plasma/kwin/-/merge_requests/5683
Not sure it helps here but it was causing QMplay2 on mesa w/ RADV (presumably this uses Vulkan somewhere?) to crash with:
"wp_linux_drm_syncobj_surface_v1@107: error 4: explicit sync is used, but no acquire point is set"
Maybe my bug is actually caused by Mutter then? @konrad are you on KDE, and if so can you try the above patch (or -git version of kwin since it's merged)?
(In reply to konrad from comment #2)
For me, the error message looks slightly different:
$ firefox [GFX1-]: Wayland protocol error: wp_linux_drm_syncobj_surface_v1@75: error 4: explicit sync is used, but no acquire point is set ExceptionHandler::GenerateDump cloned child 118029 ExceptionHandler::WaitForContinueSignal waiting for continue signal... ExceptionHandler::SendContinueSignalToChild sent continue signal to child Exiting due to channel error.
However, I think it is the same error.
Troubleshoot mode works fine, normal mode (also without addons) crashes
I re-tested this on the KDE 6.1 beta w/ explicit sync and can confirm the error changes to match yours:
[GFX1-]: Wayland protocol error: wp_linux_drm_syncobj_surface_v1@66: error 4: explicit sync is used, but no acquire point is set
So it seems the error is from the compositor, not Firefox?
Comment 5•8 months ago
|
||
There is an issue about this on NVIDIA's egl-wayland repo, and it seems that the Firefox's behavior is problematic.
Updated•8 months ago
|
Assignee | ||
Updated•8 months ago
|
Comment 7•8 months ago
|
||
In the GitLab thread about the sync protocol, this is mentioned:
With firefox I'm seeing something some extra frame and commit events get injected into my attach+syncpoints+commit cycle:
[2365871.993] -> wl_surface@63.attach(wl_buffer@67, 0, 0)
[2365872.013] -> wl_surface@63.frame(new id wl_callback@65) <<<<<< This gets added from firefox
[2365872.019] -> wl_surface@63.commit()
[2365872.039] -> wp_linux_drm_syncobj_surface_v1@55.set_acquire_point(wp_linux_drm_syncobj_timeline_v1@59, 0, 252)
[2365872.046] -> wp_linux_drm_syncobj_surface_v1@55.set_release_point(wp_linux_drm_syncobj_timeline_v1@70, 0, 84)
[2365872.051] -> wl_surface@63.damage(0, 0, 1280, 972)
[2365872.057] -> wl_surface@63.commit() <<<<<< No buffer attach in this commit
[2365872.062] -> wl_display@1.sync(new id wl_callback@77)
[2365872.139] wl_buffer@73.release()
[2365872.234] wl_display@1.error(wl_surface@63, 3, "explicit sync point set but no buffer attached for surface 63")
The issue has also been reported on the Mutter GitLab.
According to the discussions on GitHub about this, Firefox has a thread trying to write to a surface allocation that another thread has not created yet, resulting in behavior that is not allowed by the sync protocol. There is a log from Firefox and a log from Thunderbird of the issue happening.
Updated•8 months ago
|
Assignee | ||
Comment 8•8 months ago
|
||
Yes, we'd need to sync write to wl_surface. Main issue is to share lock between GL and widget code.
Is there any interim fix apart from downgrading explicit sync possible? Firefox has been crashing constantly with kwin and nvidia driver 555.
Comment 10•8 months ago
|
||
Is there any interim fix
You can run Firefox under Xwayland to work around the issue with the environment variable MOZ_ENABLE_WAYLAND=0. I have copied the desktop file for Firefox to my user's ~/.local/share/applications so that I could set that variable automatically when launching Firefox.
Comment 11•8 months ago
|
||
You can run Firefox under Xwayland to work around the issue with the environment variable MOZ_ENABLE_WAYLAND=0. I have copied the desktop file for Firefox to my user's ~/.local/share/applications so that I could set that variable automatically when launching Firefox.
That worked, thank you! I just added it to /etc/environment
and restarted.
Comment 12•8 months ago
|
||
Is there an update that is expected to resolve this? I would rather not run using xwayland as it seems to degrade performance significantly.
Comment 13•8 months ago
|
||
(In reply to jon from comment #12)
Is there an update that is expected to resolve this? I would rather not run using xwayland as it seems to degrade performance significantly.
For me Firefox reverted to software rendering in Xwayland mode, with significantly degraded performance. Setting gfx.webrender.all=true
in about:config got it back to hardware rendering and got me mostly back to normal performance.
Comment 14•8 months ago
|
||
(In reply to Karl Erik Hofseth from comment #13)
For me Firefox reverted to software rendering in Xwayland mode, with significantly degraded performance. Setting
gfx.webrender.all=true
in about:config got it back to hardware rendering and got me mostly back to normal performance.
Unfortunately this didn't seem to work for me. Half of the text won't render for some reason.
Comment 15•8 months ago
|
||
(In reply to jon from comment #14)
(In reply to Karl Erik Hofseth from comment #13)
For me Firefox reverted to software rendering in Xwayland mode, with significantly degraded performance. Setting
gfx.webrender.all=true
in about:config got it back to hardware rendering and got me mostly back to normal performance.Unfortunately this didn't seem to work for me. Half of the text won't render for some reason.
The reason it does that is because by default it is actually using the zink egl provider (can verify on about:support).
The way to workaround it is add __EGL_VENDOR_LIBRARY_FILENAMES=/usr/share/glvnd/egl_vendor.d/10_nvidia.json
This will make firefox switch to GLX basically because Nvidia EGL in xwayland is currently broken but you will get hardware acceleration and no broken fonts (the fonts issue is somehow related to subpixel rendering when using zink as I figured I can remedy the problem somewhat by flipping subpixel rendering option in KDE to something else and then back to RGB (in the case of my monitors) or None).
Still this workaround, while it provides basic hardware acceleration, it comes with a lot of caveats that I have encountered. Main ones of the top of my head is that video hardware acceleration is impossible and there's no dmabuf support.
Considering the performance issues on xwayland this should probably be higher priority as a release nvidia driver with explicit sync is coming soon and it will break wayland firefox on every system with nvidia proprietary driver.
Comment 16•8 months ago
|
||
(In reply to nodensntt from comment #15)
Thanks for the insight. I agree this should absolutely be a high priority.
Comment 17•8 months ago
|
||
Is there no ETA for a bug fix for this? I'm considering the option of using chromium as my daily driver since I'd want all my programs to be Wayland native, and this bug should be a higher priority since it breaks the experience of the browser. Firefox is better than chromium for me, but this bug is really grinding my gears. I appreciate what the developers are doing to give us an amazing experience and i thank you all for that as well.
Comment 18•8 months ago
|
||
I agree as to the potential high priority on this bug, as it makes Firefox completely unusable on the new Nvidia drivers.
Comment 19•7 months ago
|
||
I'm not sure if this is also related to this issue, but since using the v555 drivers and plasma 6.1, I've been encountering occasional stuttering in full-screen video playback, i.e. the Video runs perfectly fine, and then the Framerate seems to dip considerably until it catches back up a few moments later. This happens in a clean-profile as well and notably does not seem to be related to video buffering.
The issue is exclusive to Firefox and does not happen in chromium based browser - I'm fairly certain it is related to explicit sync support but I'm not quite certain, let me know if there is an existing report for this issue as well (could not find one) or if I should open a separate issue for this
Comment 20•7 months ago
|
||
(In reply to fynnbwdt from comment #19)
I'm not sure if this is also related to this issue, but since using the v555 drivers and plasma 6.1, I've been encountering occasional stuttering in full-screen video playback, i.e. the Video runs perfectly fine, and then the Framerate seems to dip considerably until it catches back up a few moments later. This happens in a clean-profile as well and notably does not seem to be related to video buffering.
The issue is exclusive to Firefox and does not happen in chromium based browser - I'm fairly certain it is related to explicit sync support but I'm not quite certain, let me know if there is an existing report for this issue as well (could not find one) or if I should open a separate issue for this
PS: Notably, it also does not happen when the video is not in full-screen. This happens only for full-screen video playback
Assignee | ||
Comment 21•7 months ago
|
||
Updated•7 months ago
|
Assignee | ||
Comment 22•7 months ago
|
||
Depends on D214883
Assignee | ||
Comment 23•7 months ago
|
||
Depends on D214884
Assignee | ||
Updated•7 months ago
|
Comment 24•7 months ago
|
||
Thanks Martin. We know you will do a great work in fixing this problem. Looking forward for a better Linux experience!
Reporter | ||
Comment 26•7 months ago
|
||
This is now impacting the stable Nvidia drivers since the release branch now supports explicit sync. Are the patches just needing review/testing? Firefox is fairly large so I don't usually built it myself but I'll see if I can test this in the coming days.
Comment 27•7 months ago
|
||
Nvidia 555.58 driver, Fedora 40, KDE Plasma 6.1.1, Wayland.
Google web services (docs, drive) crash firefox when hardware acceleration enabled. Crashes do not occur when hardware acceleration is disabled in Firefox 127.0.2.
Comment 28•7 months ago
|
||
(In reply to Vash63 from comment #26)
This is now impacting the stable Nvidia drivers since the release branch now supports explicit sync. Are the patches just needing review/testing? Firefox is fairly large so I don't usually built it myself but I'll see if I can test this in the coming days.
Nvidia 555.58 driver, Fedora 40, KDE Plasma 6.1.1, Wayland.Google web services (docs, drive) crash firefox when hardware acceleration enabled. Crashes do not occur when hardware acceleration is disabled in Firefox 127.0.2.
Yes. It's only related in how the NVIDIA driver communicates with the compositor. I found out that Firefox works just fine under Wayland using compositors without the linux-drm-syncobj-v1 protocol, like Hyprland. Might be because the compositor is not forcing buffer synchronization since it doesn't supports it. I'm not a programmer so i might be wrong, but what I do know is that this bug needs to be fixed and merged as soon as possible since it breaks the experience of the user. BTW you can use XWayland as a workaround if you want
Comment 29•7 months ago
|
||
Regarding to Xwayland, at least with my setup (mutter 46.3.1, Xwayland 24.1.0, nvidia 555.58.02), using Firefox inside Xwayland it won't crash but all windows contents are totally corrupted, leaving Firefox unable to be used with this combination either. If I'm not mistaken Xwayland also have implemented support for linux-drm-syncobj-v1, even that I'm not sure if this is related with this other issue, but other EGL apps work well under Xwayland.
Also, I noticed that at least in Firefox 128.0b9, using NVIDIA and with selected the "recommended" performance settings, it now automatically disables the hardware compositing (Acceleration blocked by platform), allowing the usage of Firefox under Wayland without crashing.
I assume this have been added as a temporally workaround.
Thanks.
Comment 30•7 months ago
|
||
(In reply to Pau RE from comment #29)
Regarding to Xwayland, at least with my setup (mutter 46.3.1, Xwayland 24.1.0, nvidia 555.58.02), using Firefox inside Xwayland it won't crash but all windows contents are totally corrupted, leaving Firefox unable to be used with this combination either. If I'm not mistaken Xwayland also have implemented support for linux-drm-syncobj-v1, even that I'm not sure if this is related with this other issue, but other EGL apps work well under Xwayland.
Also, I noticed that at least in Firefox 128.0b9, using NVIDIA and with selected the "recommended" performance settings, it now automatically disables the hardware compositing (Acceleration blocked by platform), allowing the usage of Firefox under Wayland without crashing.
I assume this have been added as a temporally workaround.
Read https://bugzilla.mozilla.org/show_bug.cgi?id=1898476#c15
Comment 31•7 months ago
|
||
(In reply to nodensntt from comment #30)
Read https://bugzilla.mozilla.org/show_bug.cgi?id=1898476#c15
Hello nodensntt,
This is not my case, since I didn't even have any Mesa drivers installed at all.
But I believe this isn't related with this issue, just another inconvenience that impede to use Xwayland as a workaround.
My intention was to just point out that using Xwayland isn't an option either (at least with the NVIDIA drivers).
For me I have already disabled hardware compositing and it works okish under Wayland, so no big deal here, until this issue gets fixed.
But to dig into the details, using NVIDIA EGL under Xwayland to me it creates a fully corrupted image window (and not only some texts) and it can get fixed by resizing the window. And every time it gets that corrupted again, one need to re-resize the window to fix the window contents.
I also tried forcing using the egl_vendor.d/10_nvidia.json
with my correct path and it fails the same way.
By forcing to use Zink, it will work out of the box.
To do so I had to install Mesa and I added this environment variables:
__EGL_VENDOR_LIBRARY_FILENAMES=/usr/lib/x86_64-linux-gnu/GL/glvnd/egl_vendor.d/50_mesa.json
MESA_LOADER_DRIVER_OVERRIDE=zink
GALLIUM_DRIVER=zink
But as you said using Zink works by failing back to software render, so I believe its easier to just disable hardware compositing manually and use Wayland directly.
In any case, thanks for the reference anyway.
Comment 32•7 months ago
|
||
(In reply to Pau RE from comment #31)
But to dig into the details, using NVIDIA EGL under Xwayland to me it creates a fully corrupted image window (and not only some texts) and it can get fixed by resizing the window. And every time it gets that corrupted again, one need to re-resize the window to fix the window contents.
I also tried forcing using theegl_vendor.d/10_nvidia.json
with my correct path and it fails the same way.
The thing is that Nvidia EGL under Xwayland is not working. At all. It is broken entirely. Can you check what exactly firefox says in about:support that it is using? It should be using GLX under Xwayland. Firefox should be automatically switching to GLX when using the nvidia provider after detecting that EGL is broken.
Comment 33•7 months ago
|
||
My mistake, I was looking it wrong when testing other EGL applications.
So its true about EGL not working in Xwayland, they switch to use Zink or software rendering when possible with error messages like:
mpv: libEGL warning: egl: failed to create dri2 screen
firefox: [GFX1-]: glxtest: libEGL no display
Also with my tests the rendering corruption only happen when firefox is using GLX with Xwayland with NVIDIA.
I also discovered that having MOZ_ENABLE_WAYLAND=0
will use GLX and hardware compositing with the rendering corruption bug.
But having no environment variable or having it set to 1
, while also disabling Wayland access (while allowing access to Xwayland) it always fallback to both software rendering and compositing. Having no rendering issues, but poor performance.
Not to be a problem, it's just that I find it a curiosity. :)
Thanks for the information.
Comment 34•7 months ago
|
||
Comment 35•7 months ago
|
||
Backed out for causing build bustages @ widget/gtk/MozContainerSurfaceLock.cpp
Backout link: https://hg.mozilla.org/integration/autoland/rev/0fb6382be83094550774d902bd79f88d0238b215
Comment 36•7 months ago
|
||
Comment 37•7 months ago
|
||
Backed out for causing mochitest crashes
There's also this tier 2 bustage: https://treeherder.mozilla.org/logviewer?job_id=465421991&repo=autoland&lineNumber=44833
Assignee | ||
Updated•7 months ago
|
Assignee | ||
Comment 38•7 months ago
|
||
Yes, I see the failures on Wayland try although I don't see them locally. Will look at it.
Comment 39•7 months ago
|
||
After pulling updates on Fedora 40, under KDE plasma 6.1 wayland with kernel 6.9.8-200.fc40.x86_64, nvidia 555.58.02 and Firefox 128.0-1.fc40, I can replicate Pau RE's report above. GLX is now also unusable under xwayland with heavy graphical corruption.
Only way to get firefox to display properly is to run with WebRender set to software.
So the current situation is that we have no hardware acceleration possible at all with 555 nvidia drivers at this point.
Assignee | ||
Comment 40•7 months ago
|
||
(In reply to nodensntt from comment #39)
After pulling updates on Fedora 40, under KDE plasma 6.1 wayland with kernel 6.9.8-200.fc40.x86_64, nvidia 555.58.02 and Firefox 128.0-1.fc40, I can replicate Pau RE's report above. GLX is now also unusable under xwayland with heavy graphical corruption.
Only way to get firefox to display properly is to run with WebRender set to software.
So the current situation is that we have no hardware acceleration possible at all with 555 nvidia drivers at this point.
Fedora ships the patch downstream in latest Firefox 128.0 update - https://bodhi.fedoraproject.org/updates/FEDORA-2024-f9e8f7d3a7 - so it should work fine if you use Fedora provided packages. I sorted out the issues here and will push the patches today and we may also backport them to beta.
Comment 41•7 months ago
|
||
Assignee | ||
Updated•7 months ago
|
Comment 42•7 months ago
|
||
Comment 43•7 months ago
|
||
Comment 44•7 months ago
|
||
Comment 45•7 months ago
|
||
Comment 46•7 months ago
|
||
Sorry for the triple upload and noise but I kept getting a popup error while pasting in the comment box as a code block and choosing to upload which apparently also posted the written text so far thrice without updating the UI.
Also in dmesg during the crash:
[ 381.010425] [drm:nv_drm_semsurf_fence_wait_ioctl [nvidia_drm]] *ERROR* [nvidia-drm] [GPU ID 0x00006500] Attempt to wait on invalid sync FD: 235
[ 493.641779] [drm:nv_drm_semsurf_fence_wait_ioctl [nvidia_drm]] *ERROR* [nvidia-drm] [GPU ID 0x00006500] Attempt to wait on invalid sync FD: 226
[ 587.611001] show_signal_msg: 52 callbacks suppressed
[ 587.611006] WebExtensions[12032]: segfault at 0 ip 00007f91c214c5ca sp 00007ffe3fcc1e80 error 6 in libxul.so[7f91c1663000+4dfb000] likely on CPU 15 (core 25, socket 0)
[ 587.611026] Code: d4 05 49 89 04 24 31 d2 89 14 25 00 00 00 00 0f 0b 48 8d 35 f6 61 9d 05 48 89 e7 e8 d0 c8 bb 01 48 8b 04 24 49 89 04 24 31 c0 <89> 04 25 00 00 00 00 0f 0b f3 0f 1e fa 48 89 f8 48 85 f6 74 0f 48
Comment 47•7 months ago
|
||
(In reply to rockyamethyst2 from comment #45)
I'm unable to reproduce the symptoms mentioned by nodensntt and Pau Re, zero
graphical corruption.
Graphical corruption occurs only when run on xwayland via MOZ_ENABLE_WAYLAND=0 and using GLX (not software render).
Comment 48•7 months ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/f9323daf7abe
https://hg.mozilla.org/mozilla-central/rev/a264ff9e9f6f
https://hg.mozilla.org/mozilla-central/rev/eb230ecdf8eb
Assignee | ||
Comment 49•7 months ago
|
||
Please file a new bugs for the remaining issues. I don't have NVIDIA hardware so I can't test it reliably.
Updated•7 months ago
|
Updated•7 months ago
|
Comment 50•7 months ago
•
|
||
https://crash-stats.mozilla.org/report/index/11556c48-552e-4279-a8ec-a0b3c0240713 Thunderbird, user states "Nvidia 555 on Wayland with explicit sync"
This is #1 crash for Thunderbird 128.0 esr, so the patch is urgently needed on esr
Assignee | ||
Comment 51•6 months ago
|
||
(In reply to Wayne Mery (:wsmwk) from comment #50)
https://crash-stats.mozilla.org/report/index/11556c48-552e-4279-a8ec-a0b3c0240713 Thunderbird, user states "Nvidia 555 on Wayland with explicit sync"
This is #1 crash for Thunderbird 128.0 esr, so the patch is urgently needed on esr
Also take Bug 1907511 please.
Assignee | ||
Updated•6 months ago
|
Assignee | ||
Updated•6 months ago
|
Assignee | ||
Updated•6 months ago
|
Comment 53•6 months ago
|
||
It would be great if we could get some verification that these patches improved the situation for Nightly users. I know there's some push to backport these changes more aggressively and having some confidence that they've made things better would certainly help make an informed decision in that respect.
Reporter | ||
Comment 54•6 months ago
|
||
(In reply to Ryan VanderMeulen [:RyanVM] from comment #53)
It would be great if we could get some verification that these patches improved the situation for Nightly users. I know there's some push to backport these changes more aggressively and having some confidence that they've made things better would certainly help make an informed decision in that respect.
It greatly improved the situation for me, from 100% crashing within the first 10 seconds of opening the browser to being "mostly" stable. I still get some crashes in Wayland that don't occur with XWayland, which I did not get prior to explicit sync, but they are now difficult to reproduce.
Reporter | ||
Comment 55•6 months ago
|
||
I can't reproduce this at all on 2024-07-23, marked it as verified. If there is any instability left it's probably something else.
Assignee | ||
Comment 56•6 months ago
|
||
(In reply to Ryan VanderMeulen [:RyanVM] from comment #53)
It would be great if we could get some verification that these patches improved the situation for Nightly users. I know there's some push to backport these changes more aggressively and having some confidence that they've made things better would certainly help make an informed decision in that respect.
Bug 1908825 as follow up is being investigated but I need more logging.
From recent logs it looks like we fixed all places where we need to lock the surface commits and rest of the crashes comes from third party code (according to missing log entries from Firefox).
But I'll be sure when I get logs from https://bugzilla.mozilla.org/show_bug.cgi?id=1908825#c23
Updated•6 months ago
|
Assignee | ||
Comment 57•5 months ago
|
||
Comment on attachment 9409541 [details]
Bug 1898476 [Wayland] Move MozContainerSurfaceLock from MozContainerWayland to MozContainerSurfaceLock module r?emilio
ESR Uplift Approval Request
- If this is not a sec:{high,crit} bug, please state case for ESR consideration: Doesn't work under Wayland/NVIDIA with explicit Sync enabled.
- User impact if declined: Doesn't work under Wayland/NVIDIA with explicit Sync enabled.
- Fix Landed on Version:
- Risk to taking this patch: Medium
- Why is the change risky/not risky? (and alternatives if risky): Add another mutex/lock before we commit to wayland surface or swap GL buffer. Fairly straightforward patch, already shipped downstream on Fedora and on Nightly/Beta without regressions.
Assignee | ||
Comment 58•5 months ago
|
||
Comment on attachment 9409542 [details]
Bug 1898476 [Wayland] Provide surface lock by GtkCompositorWidget r?emilio
ESR Uplift Approval Request
- If this is not a sec:{high,crit} bug, please state case for ESR consideration:
- User impact if declined:
- Fix Landed on Version:
- Risk to taking this patch: Low
- Why is the change risky/not risky? (and alternatives if risky):
Assignee | ||
Comment 59•5 months ago
|
||
Comment on attachment 9409543 [details]
Bug 1898476 [Wayland] Lock Wayland surface before Swap buffers in RenderCompositorEGL r?emilio,jgilbert
ESR Uplift Approval Request
- If this is not a sec:{high,crit} bug, please state case for ESR consideration:
- User impact if declined:
- Fix Landed on Version:
- Risk to taking this patch: Low
- Why is the change risky/not risky? (and alternatives if risky):
Comment 60•5 months ago
|
||
(In reply to Martin Stránský [:stransky] (ni? me) from comment #57)
- Why is the change risky/not risky? (and alternatives if risky): Add another mutex/lock before we commit to wayland surface or swap GL buffer. Fairly straightforward patch, already shipped downstream on Fedora and on Nightly/Beta without regressions.
There was a regression with bug 1907511 so presumably that would need to be uplifted as well.
Assignee | ||
Comment 61•5 months ago
|
||
(In reply to Mathew Hodson from comment #60)
(In reply to Martin Stránský [:stransky] (ni? me) from comment #57)
- Why is the change risky/not risky? (and alternatives if risky): Add another mutex/lock before we commit to wayland surface or swap GL buffer. Fairly straightforward patch, already shipped downstream on Fedora and on Nightly/Beta without regressions.
There was a regression with bug 1907511 so presumably that would need to be uplifted as well.
Yes, we need to take it too.
Comment 62•5 months ago
|
||
Comment on attachment 9409541 [details]
Bug 1898476 [Wayland] Move MozContainerSurfaceLock from MozContainerWayland to MozContainerSurfaceLock module r?emilio
Approved for 128.2esr.
Updated•5 months ago
|
Updated•5 months ago
|
Comment 63•5 months ago
|
||
uplift |
Description
•