2038022 - Nova border on a maximized window prevents clicking top screen edge to switch tabs and clicking right screen edge to grab the scrollbar

Status: NEW

(Firefox :: Theme, defect, P1)

Description

[Chris Peterson [:cpeterson]]

Attachment: border_screenshot.png

Steps to reproduce

I'm testing on Windows 11.

1. Set browser.nova.enabled = true.
2. Confirm that you see the window's Nova border.
3. Maximize the browser window.
4. Move your mouse pointer to the top edge of the screen.
5. Double click the browser window.

Expected result

The browser window should unmaximize.

Actual result

Nothing happens. The Nova border does not respond to the double click. This is a Fitts' law regression on Windows.

Comment 1

[BugBot [:suhaib / :marco]]

The Bugbug bot thinks this bug should belong to the 'Firefox::New Tab Page' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[BugBot [:suhaib / :marco]]

:jswinarton, since you are the author of the regressor, bug 2026246, could you take a look? Also, could you set the severity field?

For more information, please visit BugBot documentation.

Comment 3

[Chris Peterson [:cpeterson]]

Attachment: scrollbar_screenshot.png

The Nova border also prevents clicking the right screen edge to grab the scrollbar in a maximized window on Windows.

Comment 4

[Chris Peterson [:cpeterson]]

I think this change is an accessibility regression because interacting with the browser window now requires more precise mouse clicks.

Comment 5

[Chris Peterson [:cpeterson]]

Attachment: Chrome_screenshot.png

For comparison, Chrome removes its rounded window border when maximized. That resolves these issues clicking edges of the screen.

Comment 6

[Merci chao]

This issue has a significant impact on accessibility. When a window is maximized, users used to be able to simply move the cursor to the very top of the screen to select a tab, but now they have to carefully position it. In addition, on Windows, all programs allow users to click the close button by moving to the top-right corner, but Firefox’s new design is the only one that breaks this familiar user behavior.

Comment 7

[Stephen Thompson [:sthompson]]

This is behind the browser.nova.enabled pref and that pref will be disabled by default for several more releases.

I filed bug 2038764 to track the UX request to change behaviors of the window padding for Nova.

Comment 8

[Sam Foster [:sfoster] (he/him)]

:sthompson, is there a better component for this? Can you triage it - its currently in the firefox::general triage list.

Comment 9

[breakingspell]

This is also a big regression in Linux (KDE/X11/Wayland) and denies Fitt's Law and cursor memory, specifically for the top tab row.

The new exterior border prevents the topmost pixels from being used to select tabs and header buttons by cursor, requiring precision to not hit the top edge. We worked quite hard to fix this behavior a year ago, please take context from BUG 1919115.

To be 100% clear, this behavior works in full-screen and tiled modes (quick snap and custom tiling) without the exterior border. The border should only be visible in floating window mode, if ever.

Comment 10

[Mauro V [:cheff]]

My 2 cents: Edge does also have this gap between the window border and the scrollbar, but you can still click on the "empty gap" to click around and use the scrollbar (Looks like any mouse action happening inside the gap is applied to the webpage's edge as well). Could this be considered?

Comment 11

[Shado]

Please keep the padding visually even when the window is maximised, it's part of the new aesthetics. Just make the padding clickable, Chrome has the same visual padding for tabs, but are clickable. As opposed to the garbage Windows 1 explorer tabs, which have no visual padding, but have the same problem as Nova's tabs.

Comment 12

[breakingspell]

A suggestion to go along with the border being interactive (also concerns BUG 2038764):

With "compact mode" returning, hide the new borders and padding entirely when compact mode is enabled.

Bonus points to offer well-documented CSS for theming/granular control of the border beyond that, but the baseline must be an off/on state separate from the Nova styling in general, which compact mode would seem to fit. It would certainly be a well-received option if executed well.

I personally value edge-to-edge tiling environments on my devices, going to lengths to disable window borders in KDE and Windows. So far I am very anxious about Nova's design direction, but I already run custom CSS in Firefox, so it would just be another brick in the wall to remove this border and added spacing if it ships as-is.

Comment 13

[Sam Foster [:sfoster] (he/him)]

:alaskanemily, you commented elsewhere that

Non-maximized windows no longer allow scrolling at the edge of the screen

Depending on what the fix ends up looking like, that case should be covered by either this bug, or bug 2054183.

What OS/window manager are you using? If a linux, when you have a window snapped to a display edge, does document.documentElement.getAttribute("gtktiledwindow") return something?

Comment 14

[Daniel Holbert [:dholbert]]

I'm not :alaskanemily but I had the same observation, so I'll weigh in in case it's useful to have more data.

I'm used to being able to scroll (or drag my scrollbar) by moving my mouse as far rightwards as it'll go, and then clicking, and that doesn't currently work when Nova is enabled.

What OS/window manager are you using?

Ubuntu 26.04 / Wayland

If a linux, when you have a window snapped to a display edge, does document.documentElement.getAttribute("gtktiledwindow") return something?

Running that in Browser Console (Ctrl+Shift+J) spawned from a single-Firefox-window session, with Nova enabled:

• when my window is maximized or snapped to the right or left side of my screen: that expression returns the empty string "" for me (i.e. the attribute is present, but doesn't have an explicit value)
• when my window is just a regular floating window: that expression returns null (i.e. attribute not present)
• when I fullscreen my window with F11, it returns either the empty string "" or null, depending on the state my window was in before I hit F11. (if it was maximized or tiled, then I get the empty string. If it was a regular floating window, I get null.)

Comment 15

[Sam Foster [:sfoster] (he/him)]

(In reply to Daniel Holbert [:dholbert] from comment #14)

• when my window is maximized or snapped to the right or left side of my screen: that expression returns the empty string "" for me (i.e. the attribute is present, but doesn't have an explicit value)

That's promising.

:emilio, blame suggests you might know what would need to happen or who I should talk to see if we can get IsTiled() to give us a value on the other platforms?

Comment 16

[Emilio Cobos Álvarez [:emilio]]

Well, it depends on whether other platforms expose the tiled state.

On windows, it seems we can use IsWindowArranged: https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-iswindowarranged

On macOS / AppKit I didn't find anything publicly documented at least... Markus, do you know? I guess if it's not publicly exposed in the NSWindow docs we might need to try to look for some private APIs or something...

Comment 17

[Emilio Cobos Álvarez [:emilio]]

I can try to look at a way to do this in appkit once I'm on my macOS machine...

Comment 18

[Emilio Cobos Álvarez [:emilio]]

Sent a patch (well, two, another one incoming for Windows) in bug 2054879.

Comment 19

[Emily McDonough [:alaskanemily]]

(In reply to Sam Foster [:sfoster] (he/him) from comment #13)

:alaskanemily, you commented elsewhere that

Non-maximized windows no longer allow scrolling at the edge of the screen

Depending on what the fix ends up looking like, that case should be covered by either this bug, or bug 2054183.

What OS/window manager are you using? If a linux, when you have a window snapped to a display edge, does document.documentElement.getAttribute("gtktiledwindow") return something?

So the main system I'm looking at for this is OS X, where I often just drag a window to the edge of the screen, which when combined with the lack of extra WM content on the edges of windows means I can just use the edge of the screen for scrolling.

I also checked with IceWM (the main WM I use, Linux and OpenBSD, X11), but it doesn't have a special snap state for "maximize horizontally" in the first place. That just resizes the window so that the WM's window handles are just outside the screen on the edges. So it does exactly what it describes, but doesn't change the window state. FWIW this is usually how I do tiling, just manually moving windows around in IceWM, fvwm, or fluxbox.

Comment 20

[Daniel Tang]

Bug 2054999 concerns detecting fullscreen to hide the border. But it need not be a dependency.

I'm concerned about the scrollbar inconvenience much more than the visuals. It should work even in maximized non-fullscreen mode. Clicking a visible right border should redirect my click onto the scrollbar.

Comment 21

[Daniel Tang]

more than the visuals

Actually, the border started bothering me. Especially in private browsing, it didn't hide when playing a fullscreen video

Comment 22

[Sören Hentzschel]

it didn't hide when playing a fullscreen video

It does. Of course, you have to use a Nightly version to see the latest state of the Nova design.

Comment 23

[digi]

Another broken feature is Vertical tabs with auto expand on. You move mouse to screen border but cursor is not over sidebar. And tabs will not show.

Comment 24

[Paul (FxUX)]

I filed a similar bug for tabs at the left edge of the screen:
https://bugzilla.mozilla.org/show_bug.cgi?id=2053433

Comment 25

[breakingspell]

Attachment: Recording 2026-07-27 at 13.03.30.gif

Comment 26

[breakingspell]

In the latest nightly (155.0a1 (2026-07-27)), Compact Mode reduces the outer border to 1px. The top elements are still not interactive when maximized or tiled, as demonstrated in the gif.

I am preparing a custom build to identify and remove the last 1px of non-interactivity. This is a hard requirement of my workflow, there must NEVER be a border around the window.

Comment 27

[Stephen Thompson [:sthompson]]

Bug 2054183 has not been started but we will do it very soon. It will remove the outer decorations from a maximized window. Tiled windows will come after but may not be completed before the 156 release.

Comment 28

[breakingspell]

I must emphasize how critical this edge interaction is. It seems to be the most commented-on regression in the Nova spec, particularly at this point in development.

Simply removing the outer elements under conditions may still not fix the edge interaction, as shown in my example with Compact Mode (which also reduces element sizes lower than I prefer).

Please (please please) ensure this is handled without the need for Compact Mode or other user interventions like custom CSS.

Comment 29

[eight04]

This is insane. What is the advantage of this UX change? Glad we can still roll back with browser.nova.enabled.

Comment 34

[B.J. Herbison]

The top and right interfere with Firefox behavior, but the bottom and left are also problems as they interfere with page behavior. The border prevents moving to the edge to click a button or a web-page clickable region (either one one the edge or going over the edge because the page is scrolled).

Comment 37

[klausgy]

Unfortunately, under XFCE (X11) document.documentElement.getAttribute("gtktiledwindow") does not seem to detect tiling state. Would be really appreciated if the window border could be disabled in about.config, for systems which don't properly communicate it to the browser.

Comment 38

[Eugene Savitsky]

What for is this border needed for? It takes real estate from all around the screen.

Comment 40

[Stefan Heinz]

So you guys knew this was a big problem and shipped it anyway? Great. This is genuinely the worst design decision i've seen in firefox since I started daily driving it almost a decade ago, and such an obvious one at that. The visual design itself is debatable, i still think it's unacceptable for you to not expose disabling the border as an easy option. Some of us actually use computers for productivity and like having a borderless window when maximizing them. Most of your users aren't marketing people trying to come up with "innovative" new designs every 2 years that break everyone's user experiences that have been established since the product first launched

Comment 41

[Bartosz Piec]

I totally agree. What it broke is:
– cannot just move the mouse to the top right corner to close the window
– cannot move mouse to the top of the minimize button to minimize
– cannot switch to a tab easily just by moving the mouse to the top of the screen above the tab
– cannot move the mouse to the right and scroll
– probably similar problem when someone is using vertical tabs or left pane

They're all UX problems. Please solve that before going to the wide range of users.