Opened 5 years ago

Last modified 8 months ago

#16364 new defect

Add an option to resize the browser window to the "safe default"

Reported by: cypherpunks Owned by: tbb-team
Priority: Medium Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords: tbb-usability, tbb-fingerprinting-resolution
Cc: gk, madystar, sajolida, steph Actual Points:
Parent ID: Points:
Reviewer: Sponsor:


I just played with my browser window, resized it, then set it to the maximum. Then a yellow line appeared, notifying me that this was an unsafe thing to do. The only option was "OK" to acknowledge the warning.

Please add an option to resize the browser window to the initial size (when I launch the browser it is always set to some default that I assume is safer due to mass usage). If possible in the menus of Firefox or whatever is behind that Onion icon and maybe also in that warning bar.

Child Tickets

Change History (15)

comment:1 Changed 5 years ago by gk

Cc: gk added
Keywords: tbb-usability added; window size removed

comment:2 Changed 4 years ago by bugzilla

Keywords: tbb-fingerprinting-resolution added
Severity: Normal
Type: enhancementdefect

Well, that's what your Resist Fingerprinting checkbox should do when it becomes checked (from unchecked).
As there is no such warning for resizing, maximization warning could be a special way to restore the size.

comment:3 Changed 4 years ago by gk

Cc: madystar added

Resolved #20705 as duplicate.

comment:4 Changed 3 years ago by keb

It does reset when i click New Identity.
Minimization has no effect.

TBB 6.5.2 on Devuan GNU/Linux
Security at medium.

Last edited 3 years ago by keb (previous) (diff)

comment:5 Changed 3 years ago by joebt

Another consideration: accidental resizing via window border grab bars.

One suggestion is not to allow accidental window resizing at all, via dragging the window borders.
Because it's very easy to accidentally move the borders, prevent the action - at least momentarily. Popup a warning - "Do you really want to resize TBB's window? This is not recommended!"

Unless they don't know the implications of changing TBB's borders or have low anonymity requirements, probably few users intentionally drag TBB borders.

At least in Linux - maybe more in some desktops, it's incredibly easy to move the window border when clicking the scrollbar thumb, if the cursor is slightly moving. No easy way to reset window to original spoofed size.

In Linux - Cinnamon, you don't have to straddle the Fx border - just be near it when grabbing the scrollbar thumb. Most users don't completely stop the cursor before clicking the scrollbar.
The new, narrower scrollbars make the problem worse.

comment:6 Changed 2 years ago by sajolida

Cc: sajolida added

comment:7 Changed 19 months ago by gk

Cc: steph added

#29808 is a duplicate.

comment:8 Changed 19 months ago by teor

Using New Identity is not a good workaround for me. I often want to keep the current content in the window, and just change its size back.

comment:9 in reply to:  8 Changed 19 months ago by steph

Replying to teor:

Using New Identity is not a good workaround for me. I often want to keep the current content in the window, and just change its size back.


comment:10 Changed 19 months ago by mcs

Resolved #30195 as duplicate.

In that ticket, the reporter suggested that the window should automatically be restored to the default size. I am not sure how that would work, but the general idea of making it easy to return to the default size seems like a good one.

comment:11 Changed 9 months ago by Thorin

#33207 is a duplicate

comment:12 Changed 8 months ago by sysrqb

As far as I know this isn't new behavior, but (at least on Linux) if you open a new window from a running Tor Browser instance (by ctrl+n or however you do it on your platform), then that new window will be the default size. If you drag a tab from another window (such as a window that was resized) into the new default-sized window, then the moved tab will now be bound by the new window's size (the default).

We should confirm there isn't any leakage from the previous window, but as far as I know there shouldn't be. This isn't anywhere near as friendly as having a single button that "snaps" the window to the default size, but it's a workaround in the mean time. I wonder if this behavior is consistent on Windows and macOS, too.

comment:13 Changed 8 months ago by Thorin

The behavior is the same on Windows, and I was going to suggest this as a hacky workaround in the other ticket I just closed - especially if you only have one or two tabs open and don't want to lose them.

There is at least a resize event triggered when a tab is moved between windows, but I'm not sure what it leaks (e.g. see the new window test where I build an array of changes: and detect the original pre-LB size, the LB border being applied, and LB: and in older TB's, the new window clamping is bypassed)


  • open TZP (inner should be e.g. 1000 width)
  • resize the browser width so you get 1100 width (LB stepped value)
  • open new window
  • drag TZP tab to new window
  • the resize event recalculated measurements: it should now say 1000


pre-LB rendering might get leaked. Normally that would only be via - there's an upstream ticket for pre-LB rendering

manual resizing: anything leaked is not stable: do you know how hard it to get the same exact width/height when resizing - anything grabbed is meaningless
maximized: this is a repeatable/stable per device metric: but how many people would drag a tab from a maximized window?

So I don't *think* there is anything here to worry about

Last edited 8 months ago by Thorin (previous) (diff)

comment:14 Changed 8 months ago by teor

Moving a tab to a new window also works on macOS.

comment:15 Changed 8 months ago by Thorin

FWIW (if there was a serious leak and nothing else works) .. FF74+ introduced browser.tabs.allowTabDetach -

Note: See TracTickets for help on using tickets.