Open Bug 1591054 Opened 1 year ago Updated 1 year ago

Letterboxing and findbar inconsistencies

Categories

(Core :: Window Management, enhancement, P3)

72 Branch
enhancement

Tracking

()

UNCONFIRMED

People

(Reporter: simon.mainey, Unassigned)

References

Details

Attachments

(1 file)

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

Component: Untriaged → Window Management
Product: Firefox → Core

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?

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...)

Priority: -- → P3

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

You need to log in before you can comment on or make changes to this bug.