Preliminary Checks

• I have read and understood the important section above.
• I have searched existing issues and avoided creating duplicates.
• I am not filing an enhancement request.
• I have checked that this issue cannot be reproduced on Mozilla Firefox.
• I have checked that this issue can be reproduced once I removed all my Mods and Custom CSS.

What happened?

I am re-opening the auto-closed topic as instructed in #4176, #5894 and #6913.

This is still very much an issue in 1.13.2b (Firefox 139.0.4) (aarch64) on macOS 15.4.1 (24E263).

This is still a very active problem, in which around 1 in 10 times it will trigger, which as you can imagine blasting through tabs, means it occurs quite a lot in a high traffic area of the application, being the back/forward mouse buttons.

It's incredibly annoying behaviour that consistently occurs no matter if I'm focused on a web page or a sidebar.

Often the only way to get it to behave again is to switch to another tab and back, clicking within the web page area will not fix it, and sometimes even that temporary fix won't work. Then when I close that tab and switch to another one again, guaranteed it will revert back and change workspace again.

The preferred fix would be a setting that I can just turn off this feature entirely. It's not something I personally find useful at all, yet I know others might, even if its just a config toggle.

It has been mentioned that setting zen.workspaces.swipe-actions to false is a work around, but this doesn't appear to work. EDIT: This does work, you just need to reboot Zen after making the config change. However, I'm not sure if this fixes the issue, or simply stops the workspace from going back/forwards, yet still blocks the back/forwards tab behaviour.

In the last 10 minutes, I've had it happen 4 times. Closed this tab, went to another, mouse pointer in the middle of the web page and it still activated the sidebar. No matter how many times I focused the web page, clicked into it, etc. it still only dealt with the workspace. The only way to 'fix' it was to change tab, change back and click back on the webpage.

Its just a really annoying issue for something so fundamental and high traffic as mouse back/forward buttons. Especially when it overrides/conflicts with core intended functionality.

Expected behavior

As a user, When I am on a webpage/using the browser, And I press the back/forward buttons on the mouse, Then the active tab should to go back/forward in its history stack.

Actual behavior

Clicking the back/forward button on the mouse, no matter the tab/page focus or mouse cursor position, the workspace will only ever be the thing that is activated on back/forward activation

Steps to reproduce

I haven't been able to find a clear reproducible scenario, about 1 in 10 times, when I press the back/forward mouse buttons, instead of activating for the tab and its history stack, it will instead activate the sidebar and no amount of 'focusing' the active tab or web page will get it to pull focus for those buttons onto the tab's history stack.

The only way to reset the behaviour is to switch to another tab, switch back and click into the web page. Anything short of that will keep the buttons attached to the workspace.

When you click onto another tab, the whole thing resets and it will happen again with ~10 tab changes.

If I can record a video next time it happens, I will.

Screenshots and videos

No response

Version

1.13.2b

What platform are you seeing the problem on?

macOS - aarch64

What component is this issue related to?

Workspaces

Relevant log output if applicable

N/A