1591054 - Letterboxing and findbar inconsistencies

Status: RESOLVED DUPLICATE of bug 1594455

(Core :: Window Management, enhancement, P3)

Description

[Simon Mainey]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Firefox/68.0

Steps to reproduce:

• vanilla profile
• enable RFP: not strictly needed but helps with parsing all the figures
• add privacy.resistFingerprinting.letterboxing = true (hidden pref)
• open the test page [1] in two tabs
• resize the chrome so there is little top/bottom letterboxing: this is so the findbar will trigger a lettrboxing step
• in one of the tabs open the findbar
• look at the real-time metrics in the test page

[1] https://ghacksuserjs.github.io/TorZillaPrint/TorZillaPrint.html

Actual results:

• tab with the findbar shows the corrects step
• tab without the findbar is also affected, but incorrectly (because the math doesn't take into account that the findbar chrome is not present in that tab

Expected results:

pics to follow

Comment 1

[Simon Mainey]

Attachment: Both started at LB height 400px

Comment 2

[Simon Mainey]

I also thought that this would happen to the docked inspector (since it's a per tab item like findbar), but I can't replicate. Maybe I just need to find the right combo. Still trying to work out why 387: in the example:

• inner window is 424 and therefore letterbox viewport becomes 400
• findbar is 37px
• tab with the findbar: available inner window is reduced to 387 (i.e 424 less 37 findbar) and therefore the LB'ing viewport becomes 350
• tabs without the findbar end up with this 387px
• now I know where it came from

---

I wonder if letterboxing can become per tab (with fission?), rather than the current per window?

Comment 3

[Tom Ritter [:tjr] (OOTO until 4/30 at least)]

This is surprising. I don't think Fission is needed. Unfortunately, I'm not sure when we're going to have time to dig into this (and the other letterboxing bugs...)

Comment 4

[Simon Mainey]

Another weird side effect of the findbar (at least on windows)

STR

• be careful with your mouse: when selecting a tab, select it from below, don't mouse over other tabs
• resize the chrome so there is little top/bottom letterboxing: this is so the findbar will trigger a letterboxing step
• open three tabs of web content, all three will have the same letterboxing margin
• in tab A, open the findbar, and the letterboxing on that tab changes
• carefully with the mouse, select (click) tab B (it too had changed - see comment 0)
• now the weird bit: mouse-over (don't click it) the third tab (C) .. and watch what happens to tab B's letterboxing
• all three tabs have lost the findbar change

The same thing happens with ctrl-tab rather than using a mouse

This is also related to Bug 1593585 (comment 0) : note: as soon as the next tab is opened, all tabs seem to get recalculated - that was on a STR involving two open tabs, and the new tab was the third one. So it seems that as soon as a third tab is "referenced" (mousing over it, ctrl-tabbing over the thumbnail), it seems to retrigger the LB code for the current tab

However, the findbar change is not reversed if you first mouseover some other open tabs first, before leaving the tab with the findbar open - which is also weird.

So depending on how many tabs you have open, and the order in which you do things, both findbar and non-findbar tabs can 1) be incorrected rounded and 2) change on you unexpectedly

Comment 6

[Simon Mainey]

This solved by Bug 1593585#c1

closing as duplicate of Bug 1594455 where we can finally upstream all the Tor Browser changes