Firefox fails to render "Close tab" and similar tooltips

[farid-cs]

When scale is set to something other than 1, firefox fails to render "Close tab" tooltips and tooltips that appear when Minimize, Restore Window Size and Close buttons are hovered.

Steps to reproduce:

1. Use provided config
2. Open 2 firefox tabs
3. Hover over one of the tab's close button
4. Hover over another tab's close button
5. Hover over Minimize, Restore and App Close buttons one by one
6. Firefox may even crash at some point if you keep repeating steps 3, 4 and 5

Minimal config:
hyprland.txt
Sorry for the txt extension it should be lua :)

System info:
sysinfo.txt

[tekstryder]

Yuppers. Crashzilla:

• https://crash-stats.mozilla.org/report/index/ca554392-c0a1-46db-94e0-812990260613#details

Signature: [@ wl_buffer_add_listener ]

Also noted while hovering tooltips that may or may not display and/or flash, the Nvidia driver complaining.

Are you using Nvidia? See: #9853 EDIT: not Nvidia.

Jun 13 11:31:04 kernel: NVRM: VM: invalid mmap
Jun 13 11:31:04 kernel: NVRM: VM: invalid mmap
Jun 13 11:31:04 kernel: NVRM: VM: invalid mmap
Jun 13 11:31:04 kernel: NVRM: VM: invalid mmap
Jun 13 11:31:04 kernel: NVRM: VM: invalid mmap
Jun 13 11:31:04 kernel: NVRM: VM: invalid mmap
Jun 13 11:31:04 kernel: NVRM: VM: invalid mmap
Jun 13 11:31:04 kernel: NVRM: VM: invalid mmap
Jun 13 11:31:04 kernel: NVRM: VM: invalid mmap

[tekstryder]

Cannot repro on sway 1.12 + wlroots 0.20.1.

[tekstryder]

Hi @farid-cs, please obtain the relevant trace log while reproducing the issue:

• https://wiki.hypr.land/Crashes-and-Bugs/#obtaining-a-trace-log

[Lopesnextgen]

Hey Farid,

This looks very likely related to the Firefox Wayland popup/fractional-scaling path, but there are two separate things worth checking here.

1. Your system info rules out “NVIDIA only”

The reply above mentions NVIDIA, but your attached sysinfo.txt shows:

GPU: AMD Cezanne / Radeon Vega
Hyprland: 0.55.4
scale: 1.5

So if you can reproduce this on AMD, then the NVRM: VM: invalid mmap messages from the other report are probably a separate NVIDIA symptom, not the only root cause.

2. Your Hyprland stack has a small mismatch

Your log also shows:

Aquamarine: built against 0.12.0, system has 0.12.1

I would fix that before treating this as a clean Hyprland bug report. Hyprland’s FAQ explicitly warns that mismatched hypr* stack components can cause random crashes or weird behavior.

On Arch/AUR, I would clean-rebuild/update the whole Hyprland stack together, then retest:

• hyprland
• aquamarine
• hyprutils
• hyprgraphics
• hyprlang
• hyprcursor
• xdg-desktop-portal-hyprland

After that, rerun:

hyprctl systeminfo -c

and confirm the “built against” and “system has” versions match.

What I think is happening

The trigger seems to be:

scale = 1.5

Firefox tooltips, tab close labels, titlebar button hints, menus, etc. are Wayland popups/subsurfaces. Since Firefox 146, Firefox has native Wayland fractional scaling enabled by default, so with Hyprland fractional output scale this goes through a relatively sensitive path:

• fractional popup size
• fractional popup position
• buffer scale / viewport handling
• damage tracking for short-lived popups
• Firefox Wayland buffer lifecycle

That matches the symptoms:

• tooltip sometimes does not appear
• tooltip flashes
• tooltip leaves stale damage behind
• repeated hovering can eventually crash Firefox
• crash signature around wl_buffer_add_listener

There is also an old Mozilla bug in the same general family: Firefox crashing when popups/tooltips are created under Wayland fractional scaling.

Tests that would narrow this down

I would try these in order.

A. Test integer scale

Change only the scale:

hl.monitor({
    output   = "",
    mode     = "preferred",
    position = "auto",
    scale    = 1,
})

Then test again with scale = 2.

If 1 and 2 work, but 1.5 breaks, that strongly points to fractional scale handling.

B. Confirm Firefox is really running as Wayland

Open:

about:support

Check:

Window Protocol

Expected:

wayland

If it says xwayland, that is a different bug path.

C. Test Firefox without native Wayland fractional scaling

In about:config, try setting:

widget.wayland.fractional-scale.enabled = false

Then fully restart Firefox.

If that fixes the issue, the problem is almost certainly in Firefox’s native fractional scaling / popup path, or in how Hyprland handles those Firefox popups.

D. Test Firefox under XWayland as a comparison

Run:

MOZ_ENABLE_WAYLAND=0 firefox --new-instance --ProfileManager

If the issue disappears under XWayland but happens under native Wayland, that again narrows it to Wayland popup/fractional scaling behavior.

E. Try current Firefox stable or Nightly

Firefox 151.0.4 is already out, and Firefox 146 was the release that enabled native fractional scaling on Linux/Wayland by default. So testing latest stable and Nightly would be useful before this gets promoted.

What to attach if it still reproduces

If it still happens after the Hyprland stack mismatch is fixed, I would attach:

• fresh hyprctl systeminfo -c
• Firefox version
• about:support graphics section
• about:support -> Window Protocol
• Firefox crash IDs from about:crashes
• Hyprland log with debug:disable_logs = false
• whether widget.wayland.fractional-scale.enabled = false changes anything
• whether MOZ_ENABLE_WAYLAND=0 changes anything
• whether scale = 1 or scale = 2 changes anything

That should make the report much easier to classify as either:

• Hyprland fractional popup/damage issue
• Firefox Wayland fractional scaling issue
• a stack mismatch issue
• a driver-specific issue

Right now, my first guess would be: fractional-scale Wayland popup handling, with the Aquamarine mismatch needing to be cleaned up first so the reproduction is trustworthy.

Relevant links:

• Hyprland FAQ on mismatched hypr* stacks: https://wiki.hypr.land/FAQ/#symbol-lookup-errors
• Hyprland crash/logging docs: https://wiki.hypr.land/0.52.0/Crashes-and-Bugs/
• Firefox 146 release notes mentioning native Linux/Wayland fractional scaling: https://www.firefox.com/en-US/firefox/146.0/releasenotes/
• Similar Mozilla bug involving Wayland fractional scaling and tooltips/popups: https://bugzilla.mozilla.org/show_bug.cgi?id=1807798

[farid-cs]

Thank you for the response. Disabling native fractional scaling in firefox fixes perfectly but I do not quite understand what is the trade off. Though integer scale like "2" also causes problems in rendering tooltips when the feature is toggled on but no crashes.
Regarding the aquamarine version I have no idea what is causing it. I use the package provided by Arch.

[Lopesnextgen]

Hey Farid,

Thanks for testing that. This result narrows the problem down considerably.

What is the trade-off?

With:

widget.wayland.fractional-scale.enabled = true

Firefox renders using Wayland's native fractional-scale path, attempting to create buffers closer to the monitor's actual scale.

With it disabled, Firefox falls back to the older approach: it generally renders at the next integer scale and lets the compositor downscale the result.

At 1.5x, that roughly means:

• Native path: render near 1.5x
• Fallback path: render at 2x, then let Hyprland downscale it to 1.5x

The practical disadvantages of disabling it are therefore:

• larger framebuffers and textures
• somewhat higher GPU memory and bandwidth usage
• potentially more power consumption
• possible slight softness caused by compositor downscaling
• less efficient behavior when moving Firefox between monitors with different scales

At 150%, rendering at 2x instead of 1.5x can involve roughly 78% more framebuffer pixels. Whether that is noticeable depends heavily on the display resolution and GPU.

There should not be any loss of browser functionality or security. If performance and image sharpness still look normal, keeping the preference disabled is a reasonable workaround.

At an integer scale such as 2, the trade-off should be much smaller because Firefox can already render at an exact integer buffer scale without requiring downsampling.

The integer-scale result is important

The fact that scale = 2 still produces broken tooltips means this is probably not simply a “Hyprland cannot handle scale 1.5” problem.

If the behavior is:

• preference enabled + scale 1.5: broken, possibly crashes
• preference enabled + scale 2: broken, but does not crash
• preference disabled: works correctly

then the more precise trigger appears to be Firefox's native Wayland scaling/popup implementation. Fractional output scaling makes the failure more severe, but it is not the only condition required to trigger it.

That makes your test particularly useful for a trace log.

About the Aquamarine mismatch

I checked the current Arch packages, and I think my original warning about that mismatch was too strong.

Arch currently distributes:

• hyprland 0.55.4-1
• aquamarine 0.12.1-1

Both packages were built and published together on June 11, 2026. The Arch packaging history also shows that Hyprland had previously been rebuilt against Aquamarine 0.12.0.

Therefore, seeing:

Aquamarine: built against 0.12.0, system has 0.12.1

can happen with the official Arch packages. It is probably a packaging/build-order artifact rather than something you caused.

Both Aquamarine versions use the same libaquamarine.so.11 ABI. Aquamarine's project documentation says its shared-library version is bumped for ABI-breaking changes, so this patch-version difference is unlikely to explain the Firefox-specific tooltip behavior.

You can still verify that everything comes from the official packages with:

pacman -Q hyprland aquamarine
pacman -Qo /usr/lib/libaquamarine.so.11
pacman -Qkk hyprland aquamarine
sudo pacman -Syu

But if those checks are clean, I would not block this bug report on the 0.12.0 versus 0.12.1 string.

Best next step

Since the preference reliably changes the result, I would collect the requested Hyprland trace while reproducing with:

• native Wayland
• widget.wayland.fractional-scale.enabled = true
• scale 1.5
• repeated tooltip hovering until the rendering failure occurs

If possible, collect a second trace at scale 2. Comparing them may show why fractional scaling escalates the rendering failure into a crash.

I would also include this concise result in the report:

Disabling widget.wayland.fractional-scale.enabled completely resolves the issue. With the preference enabled, the tooltip rendering problem is reproducible at both scale 1.5 and scale 2, although crashes have only occurred at the fractional scale.

That is stronger evidence than the original reproduction because it separates the Firefox rendering path from the configured monitor scale.

References:

• Mozilla discussion explaining that the fallback renders at 2x and is downscaled: https://bugzilla.mozilla.org/show_bug.cgi?id=1849109#c35
• Mozilla report noting that native fractional scaling reduces texture/framebuffer sizes: https://bugzilla.mozilla.org/show_bug.cgi?id=1986254#c16
• Arch Hyprland package: https://archlinux.org/packages/extra/x86_64/hyprland/
• Arch Aquamarine package: https://archlinux.org/packages/extra/x86_64/aquamarine/
• Hyprland trace instructions: https://wiki.hypr.land/Crashes-and-Bugs/#obtaining-a-trace-log

[tekstryder]

This issue is no longer reproducible with Firefox 152.0.6 and Hyprland v0.56.0.

"Close tab" and similar tooltips render correctly as expected.

Hi @farid-cs. Please test the latest release, mark the discussion as answered, and close this thread.

[farid-cs]

Yes the issue is no longer reproducible. Thanks. Closing the issue.