1963869 - RFP letterboxing doesn't resize viewport correctly when switching tabs with devtools open

Status: UNCONFIRMED

(Core :: Window Management, defect)

Description

[Malte Jürgens]

Attachment: Screenshot_20250501_192122.png

To reproduce:

1. Open a fresh profile with privacy.resistFingerprinting.letterboxing set to true (may be hidden in about:config)
2. Open https://example.com in two tabs
3. In one of the tabs, open the Firefox devtools
4. Make sure the devtools are docked to the right side of the screen (Click the three dots > "Dock to Right")
5. Switch to the other tab

Expected result: The size of the viewport changes for the new tab, adjusting to the now missing devtools.
Actual result: The viewport for the new tab stays the same size as for the old tab, resulting in lots of empty space on the left and right (see attached screenshot).

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

:pierov, since you are the author of the regressor, bug 1556016, could you take a look?

For more information, please visit BugBot documentation.

Comment 2

[sworddragon2]

Is the specific issue the reporter sees really regressed from bug #155016 ? I'm throwing this in because that bug in a possible generic manner already exists for several years far before the patch from bug #1556016 .

Specifically in the years before I observed that opening the findbar (CTRL+F) to search something within a website causes other tabs to step now 1 unit back as well. However, the behavior was very inconsistent and janky and did not always reliable reproduce and vanish. But it is a bit since I saw that issue last (maybe a year) so my memory is slightly blurry on the exact behavior I always saw.

Does somebody know more about this issue or got it eventually fixed in the meantime? If not it might be just the same bug and more investigation might be needed to fix it.

Comment 3

[Thorin [:thorin]]

see the linked tor project issue | sworddragon - now we're using css (liek tor browser for the last few years) means LB sizes are per tab, so now findbar doesn't affect all tabs in a window. IDK why left/right docked console is weird

edit: and no it's not a regression per se: see https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42020#note_3194106

• old behaviour: the letterbox margins in the consoled-tab were subtracted from the width in the other tabs
  • i.e new tabs are 2000px
  • in one tab the docked-right-console is 350px width: leaving 1650px which LBoxes to 1600px which gives a 50px margin
  • in the other tabs they would be 2000px wide but that 50px margin is applied - so the LB is actually wrong as it is now 1950px
• new behavior:
  • the css LBing is applied the same across tabs

Comment 4

[sworddragon2]

(In reply to Thorin [:thorin] from comment #3)

sworddragon - now we're using css (liek tor browser for the last few years) means LB sizes are per tab, so now findbar doesn't affect all tabs in a window.

It also didn't affect all tabs before utilizing the recent CSS Grid changes - just sometimes so something was weird/bugged all the years. But I assume - or at least hope - all is now stabilized with the CSS Grid (besides the console issue here).

Comment 5

[Thorin [:thorin]]

It also didn't affect all tabs before utilizing the recent CSS Grid changes

It did (but I get the weird part) - the order of tabs opened and actions taken matters. Just like in current FF, a tab opened after a tab-with-right-or-left-docked-console is not affected. The same thing applied with findbar in the past - because the resize event is/was only triggered when needed - I also think there was a listener somewhere. You could also remove the findbar in a tab and the other tabs were stuck. Doesn't matter :)

Comment 6

[sworddragon2]

(In reply to Thorin [:thorin] from comment #5)

You could also remove the findbar in a tab and the other tabs were stuck.

This is what I remember, but sometimes they got unstuck afterwards for unknown reasons. And I'm almost sure previously opened tabs weren't also always affected initially but sometimes at a later point - but I might just misremember.

Or maybe just other factors influenced a bit how this bug triggered on my system in the past. Just like bug #1951690 where it is known from at least 3 people that they could reproduce it but so far I'm the only idiot that can consistently reproduce it even until today - despite even a failed fiddling around attempt to unbreak it.

But yes, it doesn't really matter so much now and it is good that this issue is fixed. But it is indeed interesting that the console now acts similar for you.

Comment 7

[Pier Angelo Vendrame]

I think I got it sometimes as well.
Probably we need to trigger a resize also when switching tabs?
However, I upstreamed the patches originally written by ma1, so redirecting the NI to him.

Comment 8

[Giorgio Maone [:ma1]]

(In reply to Pier Angelo Vendrame from comment #7)

Probably we need to trigger a resize also when switching tabs?

Actually not: the problem is that we compare the vbox.browserContainer's client size to the stack.browserStack's to decide whether to use inline styles (because the tab has extra chrome like the find bar or the devtool panel) or to change the measure for every tab / window at once (to avoid letterboxing race conditions on newly opened tabs), but while this work for containerHeight (find bar and devtool panel when docked on the bottom), containerWidth should be measured one container up, i.e. on the parent hbox.browserSidebarContainer, because that is the element where the devtools panel is docked horizontally.

The patch is fairly simple, but the question is: where should it be targeted? :)

Comment 9

[Pier Angelo Vendrame]

I think we could try to fix this here upstream directly and then backport to Tor Browser (if we can't do it by 140).