Increase the max width of new windows

added component::applications/tor browser in Legacy / Trac owner::tbb-team in Legacy / Trac priority::medium in Legacy / Trac severity::normal in Legacy / Trac status::new in Legacy / Trac tbb-fingerprinting-resolution in Legacy / Trac tbb-usability in Legacy / Trac type::defect in Legacy / Trac labels

Trac:

and even MOAR usability - the sidebar becomes useful (e.g history, bookmarks...) You could always force the sidebar width to 200px as in the pic

Mozilla released a study back in Jan 2018: https://blog.mozilla.org/data/2018/01/26/improving-privacy-without-breaking-the-web/

Here is the presentation: https://docs.google.com/presentation/d/1OVtXAnyeBLX2N1yyZoTMP9AV_6HnI3mnXwIFlOL7yOA/

slide 15: 2100 users in the RFP branch (9 branches total, equal sized branches)
slide 30: look at the color strips on the RFP column (pretty sure the blue one is screen)
slide 32: screen issues was the top deal breaker .. layout is up there too
slide 33: screen is only in RFP (1 of 9 branches) and yet it was the top deal breaker for the entire study (see slide 32)
slide 41: RFP was the third highest cause of users leaving the study

I don't exactly know what screen entails: could be lack of real estate: i.e forced new window being too small, or the browser not starting maximized. Look at the brouhaha that ensued when LBing was turned on. People are very picky about "how" things should "look" (size, position, etc)

I don't browser the clearnet much in TB: but I see scrollbars a lot: for example a google search at 1000 wide causes a horizontal scrollbar, and buttons are off screen. At 1200px no scrollbar, and buttons are visible.

slide 26: don't break top sites (look at the email ones: this ties in with workflow below)

More width helps workflow (well, to be more precise: from a tiny square to having some reasonable width - am I being biased here?)

slides 28 + 53: messing with workflow is a no-no!!

Anyway: enjoy. Class, discuss!

I still don't think 1200 as max is enough. I think 1400 is better. And one key to entropy outliers is to get more users

I hadn't noticed this ticket before, thanks for the links @thorin!

It would also allow extra space on the urlbar to add a button to reset window size to default (see legacy/trac#16364 (moved))

Are you guys seeing a theme here? Or do you want MOAR reasons? :)

Even if increasing the width to 1200 or 1400 created 3 or 6 new buckets of 'w'x'h', those buckets still wouldn't be unique - they would be populated with more than enough users. In other words, it's still useless as a FPing measure.

Would you like me to do an analysis on the top 300 screen resolutions? Are there even that many for laptops/desktops? Yes, I know factors such as task bars should be taken into account. If you want, I'll do one.

moved from legacy/trac#33282 (moved)

added Bug UX labels and removed 1 deleted label

added Fingerprinting label and removed 1 deleted label

mentioned in issue #13445 (closed)

added Icebox label

@thorin is this issue still relevant with letterboxing enabled by default?

LBing doesn't really factor, except that it cleans up rounding errors e.g accidental resizing, fubared newwin etc but needs two parts

note: LBing and newWin are desktop only, so we can ignore android issues here

regardless of what we do, inner is still protected by new win and further protected by LBing. no-one is saying to do way with these. In fact they're needed more than ever

in a nutshell (and I have been planning for two years to write this up as a proper proposal), we lie about the screen (by reporting inner). We protect inner by rounding (with LBing and new win sizes). We flat out BS about the screen, and most scripts only grab screen metrics, not inner, because of stability. Advanced scripts will still try and leverage inner which is what LBing is for

Since we flat out BS and lie about screen, why tie it to inner. Why not decouple them (screen + available screen methods) from inner and just step those in three sizes .. 2k, 4k, 8k landscape, based on inner height. This also solves the orientation spoofing, or rather, that we always report landscape. And since the minimum size is 1920x1080 (2k) then everyone's newwin size does not affect it. If some config means the browser's screen info means the browser is partly offscreen, so be it. We're lying anyway, who cares.

It literally and mathematically cannot increase entropy to do this: because we are reducing from whatever down to three and in fact newwin inner sizes would dictate everyone to report the SAME value (screen metrics) to scripts = ZERO ENTROPY. It also simplifies code, IMO. (as long we cover all the methods and orientation etc which is or should be already plumbed)

^ that was part 1

with screen metrics decoupled and at zero entropy on startup (newwin) even if users disable LBing, this reduces the risk in expanding new win startup sizes

part 2 is we need usability in TB (and FF) for uptake (and it's very painful using TB on desktop in such a tiny window, see my ranting above), and I believe sizes are irrelevant to a large degree and add no entropy, it is the aspect ratio. It needs a whatif analysis, but for example if you are 1024x768 and you open at 900x600 you are already going to be different to widescreen (regardless of the scaling)

So yeah. Leave open, this is still relevant. Part 1 is already listed upstream (and discussed in an email exchange with gk years ago), but fell on the wayside at the time - not high priority and everyone is busy. I'm not the clearest writer around, and people have misunderstood aspects of what I'm saying. To me it's been a no-brainer for 3+ years

I need to lay it all out in a proper proposal: part 1 decouple screen from inner is a simple mathematical proof. part 2 requires some number crunching

PS" sorry for the long ramble

added Needs Information label

removed Needs Information label

removed Icebox label

added Sponsor 131 Roadmap::Future labels

removed Bug label

added Task label

changed milestone to %Sponsor 131 - Phase 2 - Privacy Browser

removed Task label

added Feature label

added Desktop label

mentioned in issue #41564

I'm still digesting the info in this ticket, but fwiw I'd support this change at face value. In addition to the reasons @thorin has brought up, the current default size annoyingly triggers the first responsive breakpoint intended for tablets on many sites.

the size that most sites trigger a mobile version (or the layout flexs to mobile) is 1024 and 1040 width

probably a bit much TBH (the info) in this ticket. The simplicity of it that it comes down to aspect ratio. Actual resolution doesn't matter that much (see system scaling).

I was going to do a WhatIf analysis: i.e number crunch all common screen resolutions on desktop x various toolbar/docker heights/widths + positions x system scaling to show what each would open at - to determine how many buckets extra would be exposed, if any. is it still worth it to do this? - or is my logic sound enough?

I honestly don't think there would be many, if any, 4x3 aspect ratio users around.

changed title from new window: increase max width to Increase max width of new windows

After chatting at the dev meeting, I’d really like to consider increasing the max width to 1400px in 13.0 or 13.5. However I think we should bundle this together with any letterboxing improvements into the same release, e.g. #32324. I know they’re different things, it just makes sense conceptually to release them together.

The rest (e.g. decoupling screen from inner) is over my head, so I’ll leave that to the experts for now :)

We also briefly chatted about new windows “remembering” your last custom window size, and opening any subsequent windows at the same size for the remainder of the session. I’m not sure if there are any fingerprinting concerns here, however.

I’m not sure if there are any fingerprinting concerns here, however

Yes, there is. Each new session should reset, otherwise we're perpetuating the splintering of our small number of buckets (especially those without LBing)

edit: for usability, I could argue that a New ID could remember, but not a brand new user initiated session

I’d really like to consider increasing the max width to 1400px

I wanted to run some fuzzy number crunching where the docker/toolbar position/height was a min (0) and a max (e.g. 62 on double height on windows) and where the menubar/toolbars/titlebars were fuzzy (enabled or autohide etc) and to run that against a number of native screen resolutions and system scaling to see what were all the values that popped out in A/B. A being 1000x1000 and B being 1400x1000 to see if the number of buckets was altered. I just needed to check a few things such as those fuzzy values being affected by the system scaling (I could probably get away with them being a %).

Yes, there is. Each new session should reset, otherwise we're perpetuating the splintering of our small number of buckets (especially those without LBing)

Yep, this would be session only – requiring the user to establish the custom size per session before Tor Browser “remembers” it. From my layman’s understanding they will already have splintered themselves in that case.

I wanted to run some fuzzy number crunching where the docker/toolbar position/height was a min (0) and a max (e.g. 140 on double height on windows) and where the menubar/toolbars were fuzzy (enabled or autohide etc) and to run that against a number of native screen resolutions and system scaling to see what were all the values that popped out in A/B. A being 1000x1000 and B being 1400x1000 to see if the number of buckets was altered. I just needed to check a few things such as those fuzzy values being affected by the system scaling (I could probably get away with them being a %).

Sounds good, thank you! This will be a post-12.5 thing so there’s no immediate rush.

From my layman’s understanding they will already have splintered themselves in that case.

Only on those sites used at the non-newwin size. So rethinking this. A New ID is in actual fact a new session. So on TB start or New ID we reset. But within a session, a new window could remember current window size, and that could be quite cool - but also confuse users and removes an ability to reset the size.

I think we should also investigate down the track my awesome idea of the traffic light warning/button with options (I forget where I put it) - that is

newwin + lb working = green
ether newwin or LB is wrong = orange
both not working = red

And the button allows resetting the chrome to fix the issues (but respect the LBing setting - ot whatever, needs UX)

Only on those sites used at the non-newwin size.

Got it, thanks for the clarification!

So rethinking this. A New ID is in actual fact a new session. So on TB start or New ID we reset. But within a session, a new window could remember current window size, and that could be quite cool - but also confuse users and removes an ability to reset the size.

Either way we could use some user research here to understand user behavior vis a vis custom window sizes a little better. We could also consider pushing this feature to Mullvad Browser stable first for feedback.

I think we should also investigate down the track my awesome idea of the traffic light warning/button with options (I forget where I put it) - that is

newwin + lb working = green

ether newwin or LB is wrong = orange

both not working = red

Can you explain what you mean by “wrong” and “not working” please?

And the button allows resetting the chrome to fix the issues (but respect the LBing setting - ot whatever, needs UX)

Yeah that may be useful. We could incorporate a link/option to reset in the label in the bottom-right I’m proposing here: #32324 (comment 2899463)

The other chrome element is the sidebar, I would factor that in as well but it's almost irrelevant as newwin doesn't factor it in, but at 16/9 aspect ratio for most users these days 14/10 should allow some wriggle room

tl;dr: sidebar sucks - it's not taken into account for newwin, but it's state is "sticky" - e.g. see this awesome write up by someone who knows more than me - https://github.com/arkenfox/user.js/issues/1329#issuecomment-1013792761

We could incorporate a link/option to reset in the label in the bottom-right

Not a fan of adding UX into webcontent. Also lower corner (LTR/RTL) is used for hyperlink info. Use a chrome icon, Luke.

Can you explain

#32324 (comment 2668809) - which is like 3 years old

So the button/icon (with drop down panel etc like the slider button) has two functions

visually inform the user there may be a problem
allow the user to reset whatever to fix the problems
- this could allow us add a learn more link for LBing
- this could allow us to add a LBing toggle

right/wrong

as I see it

GREY: zoom is an issue - if zoom is not 100% this isn't necessarily wrong (it's one site the user may have zoomed to read something - we reset zoom on eTLD+1 and newtab), but it affects all the measurements (some are equivalency, some are not) .. so this is something we shouldn't evaulate
RED: ruh-roh ... not rounded and does not match newwin/LB
ORANGE: rounded but outside newwin sizes
GREEN: conforms to newwin + LBing (even if LBing is disabled) - LBing is semi redundant especially if we can get the steps in both to match (under our max newwin sizes) - see #30556 (closed)

We can almost ignore LBing and just make this only about newwin. But detecting not rounded sizes we can offer the user a toggle and learn more

/insert_coffee

^ and the ORANGE covers your maximize warning

https://github.com/arkenfox/TZP/issues/237

Note: #30556 (closed) is a blocker

We need to solidify these rules (or I guess I can wrap my head around creating multiple rule sets) in order to do the multiple A/B tests :sigh:

I will post more there

edit: OK, not a blocker, at least for my A/B whatif analysis

added Screensize label

mentioned in issue #32324

mentioned in issue #30556 (closed)

mentioned in issue mullvad-browser#175 (moved)

mentioned in issue mullvad-browser#208 (moved)

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

mentioned in issue #41919

mentioned in issue #41920 (closed)

marked #41920 (closed) as a duplicate of this issue

marked this issue as related to #41920 (closed)

@donuts and all, this is a continuation of the following discussion which was a duplicate unknowingly started by myself in the Mullvad Browser issue tracker.

Start of the discussion: #41920 (comment 2925873)

So I can offer an improvement in terms of UX to the predefined list: when the browser launches, it looks at the real screen size, and uses the biggest window size that can be contained in it, based on the predefined list.

This is working on the assumption that users will be de-incentivized to change the window size if it's taking advantage of their screen size. Without making some user research, it's hard to know whether the approach here is sound or not.

If the assumption is correct, this will minimize the number of buckets the users will find themselves in, while they don't change the default window size.

I'd 100% be in favor of a middle-ground – where we have a more generous max width/height that would prevent the window from being too large on big screens (e.g. 1600 x 1000px?).

In the same vein, I worry a little that 1200 is still too low for many desktop users and a little close to common desktop breakpoints.

I need to finish computing possible results (sorry, but its rather complex and I'm not sure how to do it TBH), but given the wide number of parameters and positions of them, it's fair to say that width can change 1 step and height 2 steps (i.e 2 heights x 3 widths = 6 outcomes) - if you're not following, I don't blame you - lets say you can just squeeze in at 1000px high with minimal'ish chrome - at max'ish chrome and windows task bar you would end up well over 200px different

Another way to look at this is just calculate all possible combos. If we add another step, we double the buckets, etc. So what if we add two width steps (1200, 1400 max) and reduced 1 height (900 max). That's only double the buckets, and since this was protection was first added, we've at least doubled our user base

PS: I am still convinced this actually doesn't do any harm

PPS: Arkenfox users, myself included, have been using 1600w x 900h for ages. At 1400x900 max TB users will be getting a major upgrade

@donuts ... if you want to play

/* 4502: set new window size rounding max values [FF55+]
 * [SETUP-CHROME] sizes round down in hundreds: width to 200s and height to 100s, to fit your screen
 * [1] https://bugzilla.mozilla.org/1330882 ***/
user_pref("privacy.window.maxInnerWidth", 1600);
user_pref("privacy.window.maxInnerHeight", 900);

Thanks @thorin! I think the general consensus here is that we're not afraid of going wider, and think our users would appreciate that more, but will take your lead here.

PPS: Arkenfox users, myself included, have been using 1600w x 900h for ages. At 1400x900 max TB users will be getting a major upgrade

Both of these sounds great 🤩

I honestly think (super gut feeling having thought about this and tried to calculate for years) that 1400 x 1000 wouldn't affect "entropy" (some edge cases e.g. portrait desktops - we will never cover all edge cases IMO), but 1600 x 1000 would. "entropy" is a bit hand wavy, I think I mean number of buckets - mathematically the possible combos increase, but do they in reality? As I said, if you can do 1000w x 1000h, you can almost certainly do 1400w x 1000w, so we really swapping one bucket for another.

A really safe bet is 1400 x 900. That's 26% more real estate that 1000x1000. Eliminates the serve-mobile-pages at under 1024px width nonsense, and 900px height is absolutely heaps (I use 900 height on my 1440px high desktop screens). On laptops, people barely get to 800px high - look at all the tickets (I dare you to find them). safe bet - only doubles the mathematical possible combos

If we want to change/increase those later based on more analysis (sorry, I'll get there with the math), we can.

When do you want a decision by - I might see if I can muster the courage to do some MATH

@thorin so we're looking to get this at least initially updated in 13.0a2 scheduled for release next week, so end of this week would be ideal (we can always update, we have a few alphas scheduled before 13.0 stable in end of September)

I haven't bothered building a UI for this, and am just modifying vars in code

Step 1:

So I am using 15 resolutions reported by moz telemetry in 2 places, ignoring some - this is resCommon

click me for details

// actual resolutions reported (i.e not necessarily native)
	// https://firefoxgraphics.github.io/telemetry/#view=monitors
	// https://data.firefox.com/dashboard/hardware
	// https://gs.statcounter.com/screen-resolution-stats/desktop/worldwide
const resCommon = [
	// anything smaller than these would have no change with expanding max width from 1000

	              // statc,    FF,  dashboard
	[3840, 2160], //         1.4%
	[2880, 1800], //                2.1%
	[2560, 1440], //  2.5%,  2.2%
	[1920, 1200], //  0.8%,  1.7%
	[1920, 1080], // 23.0%, 49.6%
	[1680, 1050], //  1.4%,  2.2%
	[1600,  900], //  3.4%,  6.3%
	[1536,  864], // 10.8%, 
	[1440,  900], //  6.0%,  2.6%
	[1366,  768], // 16.9%, 21.5%
	[1360,  768], //  1.0%,  1.3%
	[1280, 1024], //  1.8%,  3.2%
	[1280,  800], //  1.6%,         1.7%
	[1280,  720], //  6.2%
	[1024,  768], //  1.6%   2.0%
	/* ignore
		// none of these change if we up max width from 1000 to 1400
		// and none are likely to system scale bigger
	[ 768, 1024],	//  1.8%         // portrait 1.33
	[ 810, 1080], //  1.7%         // portrait 1.33
	[1024, 1366], //  0.7%         // portrait 1.33
	[ 820, 1180], //  0.6%         // portrait 1.43
	[ 834, 1194], //  0.5%         // portrait 1.43
	//*/
	              // 82.3%, 94.0%
	/* ignored
	[ 360,  800], // 1.0%
	[ 800,  600], // 0.9%
	//*/
	// other      // 15.9%,  6.1%
]

Step 2

ignored for now: use a much larger array of native screen resolutions, factor in system scaling (100, 125, 150, 200 etc - as per OS slider steps) to get resScaled - which we dedupe including where rounding causes a 1 or 2 px difference.

Step 3:

using resCommon (but as I ramp this up I will us resScaled), calculate all the permutations of the taskbar/docker height/width/position. I am just using windows measurements here but since it includes using the side of the screen it's indicative of linux as well. 0 is duplicitous, so this is each "res" x 6. This is resAvailable

click me for details

		"taskbarheight": [
			// on top/bottom
			0, // min: autohide
			30, // win 7 single height
			48, // win 11 default: can vary by 1 with various scaling
			62, // max: win 7 double height
		],
		"taskbarwidth": [
			// on side
			0, // min: autohide
			62, // default
			130, // max: user stretched it a little to read app titles
		],

Step 4

for each resAvailable we would calculate all the permutations of toggling chrome bits on/off: menu bar, toolbar showing only on newtab or off vs always, theme density - and subtract the chrome measurements. This is resInnerAvailable

for this test I only used the default (as I prototype) and used the win11 default of 12 pixels width and 91 pixels height for chrome

Step 5

for each resAvailable, run an A/B test (configurable), e.g. 1000x1000 vs 1400x1000

results

edit: these are a little off, I used round instead of floor, but the gist is the same: approx double, see later comment

click me for details

15 base real world screen res from moz
x 6 taskbar changes = 90 available screen res
x 1 chrome (default) variation = 90 availableInner sizes
A on top, B underneath

1000 x 1000 vs 1400 x 1000

6 buckets -> 12 buckets (only double despite 2 extra steps). Notice how the group of 31 in A stick together (as I said, if you can do 1000 high you can do 1400 width)

1000 x 1000 vs 1400 x 900

6 buckets vs 11 buckets , not worth the diff to drop to 900 IMO. Notice the group of 31 sweels a little

1000 x 1000 vs 1600 x 900

6 buckets vs 13 buckets .. wooo, all that extra width, holy cowabunga

1000 x 1000 vs 1600 x 1000

6 buckets vs 14 buckets

1000 x 1000 vs 1200 x 1000

6 buckets vs 8 buckets

Step 6

ramp up from a core 15 screen res as the base (use native screen x scaling)
add chrome combos (they are legion)

I suspect as I increase the number of permutations/variables, and base screen sizes, the difference in buckets will drop slightly. Each OS can be different (e.g. win10+ doesn't allow the taskbar to move to the side) and some are unlikely (e.g. win7 side taskbar widened to 130px from 62 default), so this really only tells us the max number of buckets, not the entropy of each. So I think this current (simplified) test is more indicative of real world

The other consideration is portrait desktop screens - see the first detail section above in this comment, where I ignored them. I might add them in later.

summary

of a basic quick test - what do you all think?

1200 x 1000: 8 buckets
1400 x 900: 11 buckets
1400 x 1000: 12 buckets
1600 x 900: 13 buckets
1600 x 1000: 14 buckets

PS: so I was partly right, i.e a lot of users simply move buckets, but unfortunately, also stated that I think most buckets would get edge cases, we do increase buckets - but it's not (so far) exponential, two extra steps is approx double, not 4 times. Pretty sure though we could probably get every possible newwin size with something in it with enough edge cases (we'll see when I ramp it all up)

@richard @donuts speak

bumped base res (was 15) to 74 (a ton of native manufactured res merged with those from telemetry) - total 444 available sizes for inner: current 1000x1000 6 buckets (1 bucket super sparse), new 1400x1000 = 13 buckets (2 buckets super sparse)

When I finish this, it won't be AB testing it will be auto ABCDEF testing. Another thing I can do is calculate wasted real estate per result (e.g. did we end up with 95px going to waste), and might even add in multiple-customizable size steps

edited: as I weed out obsolete resolutions like the Apple PowerBook G4!!

ughh .. SXGA+ is pretty old and causes a new bucket on it's on so looking much betterer

anyway, just a nasty thought - we could keep status quo but if height + width are both 1000, go 1400x1000 if possible, then there should be no new buckets and everyone with larger screens benefit. We don't have to abide by the old rules of 100s and 200s etc.

class, discuss!

OK, I kinda messed up. I inadvertently used round instead of floor: doesn't really change much - was 6 buckets is really 7, etc. Still approx double - edit: win10+ looks good

click me for details

using telemetry / 15 core base resolutions

using expanded screen resolutions

edit: if we reduce taskbar options to just win10+ only: only one thickness and must be on the bottom, it gets even better ... roll on ESR128 and no more win7/8*

Here's a variable option

if you can do height 1000, maxWidth is 1400
else if you can do height 900, maxWidth is 1200
else maxWidth is 1000

increases us from 7 buckets to 8 buckets

click me for details

a new toy

WIP: https://arkenfox.github.io/TZP/tests/newwinsim.html

win11 has less taskbar variations
- otherwise win7 = win10 or lower: I don't have a win10 to check the pixel changes
- will add mac soon
base res currently used is everything that comes natively + merged with moz telemetry and I included those 1.33 portrait ones
gives a PLETHORA of what if results. Screen output a bit crap ATM, so also look in console log
a lot of sizes are named so you can see where they originated from, e.g. if from XGA or WXGA - help with knowledge if these technologies are obsolete or very unlikely to be used anymore

ToDo

finalize base res (and give everything a name)
- take relevant native resolutions and scale for additional res that users can be at
- dedupe and merge with telemetry items
- maybe add everything as portrait (rotate it)
variations (currently taskbar changes x default chrome size) needs to be ramped up with multiple chrome toggling

This would then give us a comprehensive worst case scenario of max buckets (and some of the sparsely populated ones seem to be almost obsolete tech)

Tysm for all the number crunching here @thorin!

I'm going to refine it (for example, I already collect how many buckets each base size can end up in due to OS/chrome, at least three!! so far) and ramp it up. Come ESR128 I think we can do a lot better: e.g. based on portrait/picture mode and based on the height we can fit in (based on a static maxHeight), the maxWidth could be variable. We could even change the step sizes and add more steps. And we can calculate the wastage (all the data is already there). So imma going to add chrome variations x density per win7 vs win11, and increase the base sizes (native res x scaling) .. and add mac ... and linux. And I'll add in the ability to toggle e.g. locking compact density out, or hardening/resetting/removing ability to show menubar, but I get the feeling with so much movement in play from everything else, it doesn't really matter .. people gonna people!

anyway, 1400 x 900 seems reasonable (currently 7->11) and some of these may be really unfeasible (e.g. 500px high because you had a double height taskbar). So it's really a worse case.

...but I get the feeling with so much movement in play from everything else, it doesn't really matter .. people gonna people!

Haha, I feel ya :P

can't believe it's only been three years ... thanks y'all

changed title from Increase max width of new windows to Increase the max width of new windows

mentioned in issue #41935 (closed)

Yesterday, I had the (personal) epiphany that we should focus more on viewport size (also sometimes called "browser size", "window size", "virtual screen size") more than on the screen size.

This data is hard to come by, but is much more representative to user's behavior on the web.

I could only find old data, but it's interesting to observe the difference between the screensize and the viewport.

I touched on this in one of the other tickets (kinda!). I wondered if the simplest way to "calculate" things was to just get some available screen - minus chrome buckets from moz telemetry (touching on what tom said about possible leveraging upstream). Because there are two purposes here: keeping RFP newwin size buckets to x, and usability + discouraging the incentive for users to resize. I think I can calculate things and based on current telemetry on screen sizes get a feel for how fat/thin buckets are.

Telemetry which tells us non-RFP users' viewport (bucketize results) would be super accurate as it accounts for all OS + chrome variables. And we could add one for startup state (maximized, windowed). Worth doing IMO. That said, I don't see how we move to (initially) anything but 1200x1000, 1400x1000 or 1400x900

Yesterday, I had the (personal) epiphany that we should focus more on viewport size (also sometimes called "browser size", "window size", "virtual screen size") more than on the screen size.

Um ... yup. That's what this has always been about. We currently tie screen/outer etc to "inner window" and tidy inner's viewport with LBing

anyway, I opened #42066 to follow up, because I know we can do better