Re-evaluate letterboxing dimension choices

At some point, maybe we should reconsider our choice for letterboxing dimensions.

This ticket is primarily to serve as a place to attach my ipython script for safekeeping for years from now.

added component::applications/tor browser in Legacy / Trac owner::tbb-team in Legacy / Trac priority::low in Legacy / Trac severity::normal in Legacy / Trac status::new in Legacy / Trac type::enhancement in Legacy / Trac labels

Trac:
Content_Resolution_Analysis_10_.ipynb

Many comments about this are in the blog posts for 9.0.x and alphas. For example, https://blog.torproject.org/comment/285096#comment-285096

https://blog.torproject.org/aggregation-feed-types/tbb-90

moved from legacy/trac#30556 (moved)

added Feature label and removed 1 deleted label

removed 1 deleted label

mentioned in issue #40067 (closed)

@richard needs a Fingerprinting label, thanks

added Fingerprinting label

added Icebox label

removed Feature label

added Task label

added Sponsor 131 label

changed milestone to %Sponsor 131 - Phase 5 - Ongoing Maintenance

added Desktop label

added UX label

added Screensize label

mentioned in issue #33282 (closed)

This is a blocker for #33282 (closed) (which is hopefully post 12.5 sometime)

LB steps as follows

• under 500 in 50's
• 500 - 1599 in 100's
• 1600+ in 200's
• no distinction made between width and height

NEWWIN doesn't step, it just uses 100's for height and 200's for width (capped at max width/height)

• https://searchfox.org/mozilla-central/source/dom/base/nsContentUtils.cpp#2495-2546

Note: I always go width x height

Testing by setting maxInner's to 400 my newwin was 450 x 400, the width here is not adhering to 200's because windows cannot get under 450 (windows at least, the exact 50'ness is a coincidence) due to chrome elements - I think the size is hardcoded somewhere. And therefore at 200's width stepping 500 is also 450.

Currently, using 600 and over for width

600 x 500
700 x 500
800 x 500, etc ?

600 x 600
800 x 600
1000 x 600

600 x 700
800 x 700
1000 x 700

600 x 800
800 x 800
1000 x 800

600 x 900
800 x 900
1000 x 900

600 x 1000
800 x 1000
1000 x 1000

some of those are unrealistic, such as 600 wide by 1000 tall (landscape desktop - I guess users could have portrait monitors, but IMO unlikely at those low res)

OT: adding 1200 and 1400 only slightly increases the buckets at most (sticking to 200s width, 100's height - and some of those become really unrealistic such as 1400 wide by 600 high - my fuzzy number crunching will tell a better story)

NEWWIN is a subset of LB, so LB will always fit/match NEWWIN (as long as maxInner values are not over 1600). LBing allowing some sizes inbetween doesn't hinder newwin, but allows users should they maximize/resize within our maxInner's. Which is what it is designed for - usability should the user resize.

So in hindsight I think this isn't a blocker, and we shouldn't align LB and NW steps

Class discuss, or not! Sorry for the noise @donuts

+1 for WONTFIX

since it's now NEXT

we should align the steps, because LBing allows smaller steps, a new win size error (e.g. being a few pixels too small could force a LB size that doesn't match newwin steps = more entropy

@thorin & @donuts:

Just to be sure, if we set the newwin max width to 1600 and keep the height at 1000, as it seeems to be the current consensus, we don't need to touch LB steps and we can close this, right?

95% sure we will go with 1400 as a max width, maybe drop height by 1 step to 900. Am furiously coding a whatif newwin calculator as I type (sooo many parameters, it's exponential). Regardless of our final size, the steps are out of sync

Here's an example

• newwin expects to open at 1000 width (or 1400)
• but code is off due to some dPR/dPI issue, or user bumps the chrome smaller
  • LBing kicks in and we end up at viewport (webcontent) at 900 width (or 1300)
• outlier case but stranger things have happened: user at 800 drags the the chrome bigger, ends up at 900
• odd numbered 100 widths are not newwin steps
• in these cases the user will be an outlier

hope that makes sense. Just align LB/newwin steps exactly the same

tl;dr: I think this is the only diff (but someone should check)

• LB steps widths at 100px from 600-1600, but newwin widths in this range step 200
• LB heights over 600px is always 100px + for newwin - right?

Links

• NW: https://hg.mozilla.org/integration/autoland/rev/ad5841073c68#l4.36 also line 93 - original patch
  • lives here now: https://searchfox.org/mozilla-central/source/dom/base/nsContentUtils.cpp#2593-2598
  • and here: https://searchfox.org/mozilla-central/source/xpfe/appshell/AppWindow.cpp#1122-1123
• LB: https://hg.mozilla.org/mozilla-central/rev/6d2d7856e468#l2.34 - LBing permalink, not changed since

So, independently of what we end to pick as the initial newwin size (always multiples of 100px, both for width and height), we should be good by just forcing newwin to round at 100 instead of 200 also the width, like it does for the height.

Correct?

by just forcing newwin to round at 100 instead of 200

Nope. That would increase the number of possible newwin sizes, which we are trying to control. AFAICT we just need to make LBing where it steps in 100s width to 200's. Align LB to newwin, not newwin to LBing :)

but hold that thought, because I think we should use a variable newwin maxWidth based on newwin height - e.g. #33282 (comment 2929358) .. so I think #33282 (closed) should block this issue

^ although to be fair, #33282 (closed) is not changing the width steps (yet), so not really a blocker

removed Icebox label

added 13.0 stable Next labels

mentioned in issue mullvad-browser#208 (moved)

marked this issue as related to mullvad-browser#208 (moved)

mentioned in issue #41935 (closed)

mentioned in merge request !718 (merged)

mentioned in merge request tor-browser-build!773 (merged)

!718 (merged) in tor-browser and cherry-picked on base-browser and mullvad-browser.

marked this issue as related to tor-browser-build#40901 (closed)

Closing for now since it's merged as 200x100 alignment with new win for alpha testing. Feel free to reopen for next alpha if needed.

closed

assigned to @ma1

marked this issue as related to tor-browser-build#40902 (closed)

marked this issue as related to tor-browser-build#40965 (closed)

marked this issue as related to tor-browser-build#40966 (closed)

this is meant to be uplifted - do we reopen it, add a Uplift label, open a bugzilla, add it to the meta uplift .. wot do? @pierov

Usually keep open until Uplift 'ed, add Upstream if there's a Bugzilla, and close when uplifted.

@tjr what do you think of the current defaults of Tor Browser? The step is 200x100 and the default is 1400 x 900.

I don't have an informed opinion. If we are able to do the fingerprinting data collection project, then I might be able to make an informed opinion.

I am fine with uplifting whatever you are doing to minimize patches.

https://bugzilla.mozilla.org/show_bug.cgi?id=1556002

also don't forget to change the max newwin sizes prefs to 1400 x 900

added Uplift label