border around webpages [invalid: RTFM and duplicate of 679 - letterboxing]

[hollunder]

Hi there. I just spent a lot of time tracking down why I suddenly had a white border around every page after updating to Firefox 67. Eventually I tracked it down to this preference.

It's a rather invasive optical change and hence I don't think it's a great idea to have this enabled by default.

I suppose it's intended to make canvas fingerprinting harder, but my understanding is that the dimensions are just a small part of that and that there may be other and better ways to combat that practice.

[claustromaniac]

Letterboxing helps against screen size fingerprinting (not canvas). RFP alone protects against this too, but it requires you to use the browser at its default window size (neither resize it, nor maximize it). These features round down the viewport inner window's width and height to make us look slightly less unique. It's not a perfect approach, but there are no alternatives available as far as I know.

https://demos.traudt.xyz/css/media/index.html https://arthuredelstein.github.io/tordemos/media-query-fingerprint.html

If you don't like/need letterboxing, feel free to add it to your overrides to disable it on your end, but the pref should stay in the user.js. Even if the pref was removed from the user.js (or made inactive), IIRC letterboxing is going to get merged into RFP at some point, and we will no longer have any way to disable it (other than disabling RFP wholly).

[Thorin-Oakenpants]

It's a rather invasive optical change and hence I don't think it's a great idea to have this enabled by default.

It's no more of an "optical" issue any more than controlling your browser (chrome) dimensions.

What it does is make sure that external factors do not cause leaks outside preset sizes (steps of 200x100). External factors being: changing toolbar density (with toolbar enabled), changing themes can also do this, manually resizing the chrome, going fullscreen, maximizing, toggling numerous chrome elements (sidebar, toolbars, menubar, etc). There are still some issues (devtools if docked, findbar). And due to new window sizing being broken since FF57 when photon landed (if you have a toolbar showing with at least one icon, then the sizing is basically always out by a various numbers of pixels depending on OS and density = more entropy that shouldn't be there). Letterboxing actually also fixes that.

Enabling letterboxing is not about visuals. Fuck visuals, pardon my French :) If you're serious about anti-FP'ing, then you put up with it (or learn to resize your chrome to match = super easy). Letterboxing actually allows you MORE FREEDOM with less FPing than before: now you can do all those external things (maximize, fullscreen, etc) and be confident that at least all your screen/window etc FP metrics are at least in some sort of controlled bucket for anonymity.

As :cat2: said (cuz he follows my shit), it will get tied into RFP proper eventually, after they work out the stepping buckets etc, and may enhance or replace new window sizes.

---

Learning to resize your chrome

Here's what I do. I have a 1440p main monitor, and I use the two prefs in 4502 to set my size on startup, which happens to be 200'sx100s

user_pref("privacy.window.maxInnerWidth", 1600);
user_pref("privacy.window.maxInnerHeight", 900);

However, due to the new window sizing issue from Photon since FF57, because I have my toolbar open, I end up with a size that is short in height, e.g 1600x897 = ugh, letterbox kicks in and I have a top and bottom white letterbox

But I use this extension Window Resizer and I configured it with three presets: 1980x1020, 1900x600, and 1366x768

Note that the values are the browser dimensions, not the inner window.

So when I start FF, the first thing I do is flick down the icon menu from my toolbar, and click my 1614x1010 size and I'm adjusted to a perfect 1600x900 inner window.

I actually like the letterboxing now, as it reminds me that I'm at the wrong size due to that bug

[Thorin-Oakenpants]

and I configured it with three presets: 1980x1020, 1900x600, and 1366x768

And of course with letterboxing, two of those presets are now useless (I never used them anyway). But I could add others that conform to 200sx100s - assuming it stays that way. Already the stepping has been changed to allow smaller steps at lower sizes. And it might make bigger steps in higher sizes. And they may add in some common screen resolutions (which is nice for full screen). Nothing has really been decided yet.

[aesthicc]

ResizeIT ResizeIT 2, another window resizer

[hollunder]

Maybe it will get a better implementation at some point, but until then I have disabled it. My proposal was about saving other users the hours required to figure out what the hell is wrong when they see this.

[claustromaniac]

My proposal was about saving other users the hours required to figure out what the hell is wrong when they see this.

That's alright but, unfortunately, they'll have to spend those hours to figure it out eventually anyway, regardless of what is done with that specific pref in the user.js.

By opening this issue I'm sure you already saved others time, though.

[Thorin-Oakenpants]

That looks awesome .. makes me feel all safe and anonymous :) But yes, if you weren't expecting it, it can be a WTF is this moment - hence the FYI sticky. The other thing is it's not tied to RFP, so even users who have RFP off via an override, will feel it. I thought about sticking up a FYI a couple of days ago, and I've mentioned it before, I think in the last changelog.

Speaking of changelogs - I've been busy, but I would have hoped to have had the diffs done by now, and THAT changelog would have screamed out about letterboxing.

Still, that only informs users who bother watching or come here to check something out. And I bet if it was off, but then got tied to RFP it would still unsettle lots of people. Better sooner than later :) But those of us who use screen dimensions as advised are sweet AF .. just saying :)

Maybe it will get a better implementation at some point

What's wrong with it?

[beerisgood]

I wonder why every page looks like a own Frame. Not realy a good solution and definitely not a small "visuals" problem.

[Thorin-Oakenpants]

I wonder why every page looks like a own Frame.

Because it does. It's encapsulated inside a letterbox element

Not realy a good solution and definitely not a small "visuals" problem.

Its a fantastic solution: as it mitigates a lot of user behavior, chrome behavior, and other bugs and it reduced complexity (e.g having to handle warnings when people maximize etc)

The visuals are annoying, but end-users should never have been changing their dimensions in the first place - this just shows them now how lax they've been (increasing their entropy). So it's a Fing awesome patch IMO.

[beerisgood]

Can't agree with you I always use maximized window and every site loose a lot of width (my screen is 1920x1080) and a little height - which isn't so important.

I never change any dimensions so this new behavior is really annoying for me and I disable it IMHO

Edit: also I don't get it why customize the screensize (with add-on) would help. Doesn't bypass this the letterbox feature?

[KOLANICH]

IMHO: instead of having margins

• just size of a window should change stepwise - it gives immediate understanding that set of sizes of a window is limited and prevents confusion by margins being shown;
• maximization should be forbidden, instead when activated, the stuff should determine the largest acceptable size and set it.

[claustromaniac]

@KOLANICH, I agree that sounds like a better approach, but only if it ensured that changes to the GUI outside of the inner window never affect the inner window size. It sounds like that would introduce more code complexity though.

[crssi]

Isn't a bit too soon for letterboxing until it gets as default? I have a feeling that now with letterboxing we stand out even more?

[claustromaniac]

Letterboxing merely improves on one thing that RFP was already doing (lowering entropy from screen width/height). Considering we were already using RFP, what makes you think letterboxing can make us stand out more?

[GIPeon]

Aren't the predefined 200x100 steps making the resolution more unique being so perfectly rounded compared to common resolutions? Isn't the 1366x768 resolution the most common? Is there a recommended resolution with letterboxing?

Btw @aesthicc thx a lot for the extension very helpful!

[claustromaniac]

As I understand it, what makes spoofing the resolution a more complex task than spoofing other data (like the UA), is that the web content running in the browser needs to know your true resolution (or at least your inner window's true resolution) so all of its elements are displayed in the right size for your device. The fact that CSS and JavaScript can leak that info to the servers is a separate thing.

If all of us, RFP users, were to spoof our resolution as a fixed value (like 1366x768), users with lower native resolutions would see everything too big (even for their small screens), and users with higher resolutions would see everything too small. That's why the approach instead is to set the inner window's width and height to the multiple of 200x100 nearest to your resolution. This way, if CSS or JavaScript leak that info, they leak the same resolution as a subset of other RFP users (not a potentially unique value), and web content still displays correctly in your device.

In this and other aspects it becomes evident that RFP is not trying to make RFP users blend in with the (larger) crowd of non-RFP users, but rather blend in among themselves. It makes sense to me, considering that these things came originally from the Tor Browser, and the Tor Browser does not try to conceal the fact that their users are using that browser.

[Thorin-Oakenpants]

Is there a recommended resolution with letterboxing?

No. At the moment it's new, and just steps in 200s x 100s. The next release has a sliding scale where at smaller sizes the steps are smaller (in order to use as much real-estate as possible). In the future, they might make the stepping on higher sizes larger. The less possible combos of steps, the less buckets = less possible entropy. It is also possible they may allow common screen resolutions when in fullscreen: e.g think about watching a movie in FS on your 1920x1080 monitor. They are also meant to make the background black/dark when in fullscreen. I tried to find the element for a userContent tweak but couldn't find one.

They are also going to pull some telemetry on what what people are using, and they'll get feedback from TB 9alpha users when it gets turned on. Tor Browser backported the patches

So long story short, use what you want. It will get refined over time. Or disable it. Or @beerisgood use the other letterboxing pref to add your maximised inner window size - read 4504

Aren't the predefined 200x100 steps making the resolution more unique

No. They are ensuring that the set of RFP users (or TB users in their case) are limited to a number of buckets. This allows more scope in having bigger windows rather than everyone trying to stay at 1000x1000 or 1000x900 etc. It does increase entropy, but now imposes some sort of entropy limitation on those who resize the browser. What the rest of the world uses is immaterial.

As for common screen resolutions - they are also immaterial. The mechanism uses the real inner window as a base (so websites work properly), and the chrome has to fit around that. Unless you are at fullscreen, then that doesn't make sense. In order to get the most real-estate possible, stepping is the way to go. And again, as long as RFP (or TB) users are the same, who cares.

In other words, RFP ties all metrics (screen, available screen, outer, inner, css @media, to the same metric - and that metric is the inner window. So if a FP script wants your screen res (which is what most use, since it's a stable metric), it will get your actual inner measure. For practical purposes, trying to fit common screen resolutions into other screen resolutions while still using the browser chrome, is silly and problematic and adds complexity. It's not about looking like the rest of the world, it's about balancing usability but limiting entropy.

[claustromaniac]

Why didn't I just wait like... 1 more minute so I could save myself from typing all that stuff? 😆

[Thorin-Oakenpants]

I corrected your post with my wisdom

inner window = well, you know. viewport = inner window less scrollbars [edit: technically, less non-floating scrollbars]

[claustromaniac]

inner window = well, you know. viewport = inner window less scrollbars

Right you are.

It's mostly semantics though. TBH, I'm more focused trying not to fuck up grammar too much, so those errors are expected. Thanks for the correction.

Edit: care to correct my previous posts as well? Edit²: Alright. I fixed my posts for posterity.

[Thorin-Oakenpants]

No, you're a big cat now, wearing big girl cat pants

[GIPeon]

Thanks a lot both for this detailed information!

In this and other aspects it becomes evident that RFP is not trying to make RFP users blend in with the (larger) crowd of non-RFP users, but rather blend in among themselves. It makes sense to me, considering that these things came originally from the Tor Browser, and the Tor Browser does not try to conceal the fact that their users are using that browser.

Very interesting! I guess that this could be used aggressively (already has maybe?) like anti-adblock script "remove RFP to view content". :open_mouth:

Thank you for your time!

[KOLANICH]

If all of us, RFP users, were to spoof our resolution as a fixed value (like 1366x768), users with lower native resolutions would see everything too big (even for their small screens), and users with higher resolutions would see everything too small.

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

I guess that this could be used aggressively (already has maybe?) like anti-adblock script "remove RFP to view content". 😮

There are already solutions doing that: reCaptcha v3 and even v2 was known to be doing that, presenting such users with increased amount of screens.

[KOLANICH]

Don't confuse this with reCaptcha's anti-bot mechanisms

It is essentially the same scheme. There is a category of visitors an owner of some site wanna discriminate against. And let's assume he can't make each user to identify himself with a government-issued ID or things tied to it like a cellphone account because he afraids it would cause big churn (though in my opinion it won't and every useful and irreplaceable website can start doing that right now with only very minor churn). So he has to rely on browser fingerprinting. So if he wants his strategy to be effective, he needs to discriminate against RFP users too, othervise the discriminated category would just use RFP.

[claustromaniac]

Very interesting! I guess that this could be used aggressively (already has maybe?) like anti-adblock script "remove RFP to view content".

Indeed. That's kind of a downside, but this is still the only sane strategy for lowering entropy, because it works on the realistic assumption that everyone else (i.e. non RFP users) has a unique fingerprint. When you look at just how many metrics exist (and how many keep popping up as browsers evolve), you realize this really is the only effective way to go about it.

@KOLANICH

Nice. Too bad they set it at P5 priority level, but I guess that was to be expected, since it's a more complex take on the issue. I'm sure there must be other factors involved too. Maybe if someone had made that proposal much earlier they would've gone that route instead.

[thacoon]

I also wanted to disable this feature and added user_pref("privacy.resistFingerprinting.letterboxing", false); to my user user-overrides.js and run the updater script. However, the white border around webpages did not disappeared. In my user.js file I searched for user_pref("privacy.resistFingerprinting.letterboxing", true); (at line 1502) and commented it out, but the border did not disappeared. But when I set it to false instead of commenting it out the borders disappeared. Therefore my overrides in this case which are at the end of the file had no effect in this case. Any idea what is going on? Because I dont want to change the user.js file each time.

[Thorin-Oakenpants]

and commented it out, but the border did not disappeared

That's not how the user.js works. Commenting it out only stops it being written back into your prefs.js => about:config. You have to reset it in about:config see here

the other stuff

If you add an override, then it should be applied. You might have a syntax error somewhere. Add this to the very last line of your user.js and restart and check what it says in about:config for the parrot

// OVERRIDES
user_pref("privacy.resistFingerprinting.letterboxing", false);

/* END: internal custom pref to test for syntax errors ***/
user_pref("_user.js.parrot", "yay, letterboxing was disabled");

Edit: Also unsure where your overrides are. And the updater script. Do you mean the overrides are not added to the user.js when you update? Are you on Windows or Linux or Mac

[Thorin-Oakenpants]

@crssi setting it as false in overrides works as it should. It's a boolean. You can't set it as a string.

[crssi]

What a fool I am. You are right. I have forgot to put ; on the end of pref, and it was a syntax error. But funny thing that user_pref("_user.js.parrot", "Eagle has landed!"); as the last line was success. IDK.

[Thorin-Oakenpants]

https://github.com/ghacksuserjs/ghacks-user.js/wiki/1.1-Overview

:exclamation: In FF60+, not all syntax errors cause parsing to abort, see this article

[thacoon]

I have the updater script and my overrides in my firefox profile dir on Linux. The overrides are written to the user.js. But I am just a fool too. It works I forgot an ; at another user_pref, now it works. Classical syntax error.

[ivankra]

I'd like to argue this should be disabled by default. This is a very invasive change similar to disabling javascript, that will frustrate most of the users. You don't disable javascript by default, so then why enable this? Both have their security/privacy benefits, disabling js has more benefits, with correspondingly more annoyance to users.

In fact, it's even worse - with javascript many if not most sites in the world at least would tell you about js being disabled. Plus you can disable it selectively on a site by site basis. With this change, you just see the stupid border and you don't know what the f is going on! I kept postponing upgrading my firefox browser for a month because of this thing and only looked deeper into it today after news of another firefox 0-day. Still it took me half an hour to get to the bottom of this and I'd consider myself an advanced user. Your average user will just tell you to go screw yourself.

[claustromaniac]

You don't disable javascript by default, so then why enable this?

with javascript many if not most sites in the world at least would tell you about js being disabled. Plus you can disable it selectively on a site by site basis.

Javascript can be disabled selectively (like you said) via extensions like uBlock Origin, uMatrix, NoScript, etc, and people should be using such extensions whether they use this user.js or not. Disabling javascript globally via about:config would break more than half of the Internet for no good reason.

On the other hand, letterboxing does not break anything. Like it or not, it is only a visual change. Additionally, there are no extensions out there capable of doing anything about the screen resolution as a fingerprinting vector, and I'm pretty sure there will never be such extensions, given how limited webExtensions APIs are designed to be.

Moreover, as previously stated here, we are aware that letterboxing is going to become a proper part of RFP eventually, and when that happens there will no longer be any way to disable it without having to disable RFP entirely, regardless of this pref.

The most important thing that everyone should remember is that this user.js is a template. Users are meant to fine tune it to their own tastes/needs, because we can't realistically hope for any single setup to be perfect for every person and every use case in the known universe. That's not to say that feedback is not welcome (it really is!) but if we were to worry about every single thing that can annoy users, well... why bother maintaining this at all? If that were the maintainers philosophy, everything should be commented out by default (because that's the only surefire way to avoid surprising users), but that would mean a whole lot more work for users, and many of them don't have the knowhow or the time to research on their own, and just want someone else to make some decisions for them, or at least use those decisions as a baseline for making their own.

[ivankra]

Most users don't really tweak settings, at least not much. I think you're still responsible for finding a good balance between usability/privacy for your typical users (who are not the mainstream users who are fine with firefox's defaults, btw) and my opinion strongly is that you made the wrong call on this option.

Maybe if Mozilla had a better UX around it and it wouldn't be such a pain to find out what the heck was going on with the browser, then I could have accepted it. But as is currently, it's just plain unsuitable for most users. Even Tor Browser doesn't ship with it enabled, they have something else (warning against maximizing the window).

Sure, it's just cosmetic, but it's a very annoying cosmetic issue that is not obvious to find out. Another example of cosmetic issue I could of think is SVG - you didn't disable svg by default either despite minor security risks with it.

You caused me personally (and likely many others) to waste a lot time to debug this issue and miss out on updating my firefox for a month because I thought this thing was a firefox's glitch, and worsened my security as a result instead of increasing it - maybe I got owned by that 0-day from the news in this time.

[claustromaniac]

Most users don't really tweak settings, at least not much.

Even if that were true (I honestly don't know myself), the point still stands. This is a template, and users are expected to override stuff when it doesn't suit their needs/wants.

I think you're still responsible for finding a good balance between usability/privacy for your typical users

Responsibility is a somewhat strong word to throw around, in my humble opinion. All being done here is non-profit, voluntary work, and is provided without warranties of any kind (see the license). That aside, we do seek such a balance, and there's even an intent to eventually include a relaxed variant precisely with that in mind (it's kind of a low priority though).

Another example of cosmetic issue I could of think is SVG - you didn't disable svg by default either despite minor security risks with it.

Actually, SVG is not left enabled merely for cosmetic reasons. Disabling SVG actually breaks stuff. The explanation given in the user.js itself mentions interactive controls that use SVG for their icons, as an example.

You caused me personally (and likely many others) to waste a lot time to debug this issue and miss out on updating my firefox for a month because I thought this thing was a firefox's glitch, and worsened my security as a result instead of increasing it

I'm sorry to hear that you had to waste so much time (I really am), but you have to realize that no-one here is to blame for your personal choices. For the record (and maybe I should've made this clear beforehand), all of this is my personal view. Others may not fully agree with it, but, in my humble opinion, no matter how much effort is put in making this user-friendly, users will always have some degree of responsibility.

I agree that we must strive to make responsible decisions ourselves (even if the project is provided without warranties), because users are entrusting us with their security and privacy, but that is an ethical choice (not an obligation), and users are responsible for whatever they do or stop doing with their own shit anyway.

Again, this is my point of view. Maybe @Thorin-Oakenpants or @earthlng or others disagree, but I doubt it.

[Thorin-Oakenpants]

Without wanting to rehash everything, here was my thought process (and I did initially miss something which doesn't change the decision I made, but highlights something extra I could have done)

• we set RFP and FPI as actively true
• we have always alerted new users (and in the user.js itself: readme, and now tags) about these two items (e.g wiki): when I get time I will have to re-check exactly what is said/tagged and where: and we can always do better
• LB addresses a lot of RFP screen/window measurement shortcuts shortcomings
• cogito ergo sum: it's a no brainer to enable this as active true as well
• and we know that LB will (I'm 99% sure) become enforced / merged with the RFP pref at some point (whether it enhances or replaces new window sizes is a different issue)
• sooner or later RFP users will need to "deal with it" (for lack of a better phrase)

The bit I (kind of) didn't totally factor in

• because it is currently a separate pref, by making it active we affect two distinct sets of users
  • set one: those who have RFP on
  • set two: those who don't: i.e they override it
• I did not really consider set two. RFP users, on the other hand, can live with it IMO. Either you're serious about anti-FPing or you're not.

Communication

• Because I didn't really factor in group two, I should have done more in highlighting this
• I'm impatient AF and I treat open issues as a challenge to solve as fast as possible. An empty issues list is a happy list. And I don't like pinning shit (IDK why, maybe I'm just weird). I probably closed this too early, and I unpinned it too quick.

Add to this, that not every user has the time to read what we do here, or follow the changelogs etc. And we could have done better to indicate this change (more on that: e.g wiki, readme) - that's on me.

Both sets of users will get a bit of a surprise. While it doesn't break anything functionally, the visual can be a bit distracting in a few ways: no one likes unexpected changes, and the whiteness is definitely off-putting to some people. And some people like to resize their browser, or use FS, or maximize, and even with RFP on, new window sizes are out by a few pixels if you have the toolbar on: usually too short (depends on your systems DPI settings) and thus: whammo: everyone (both sets of users) will end up with letterboxing.

So long story short: this "surprise" affected everyone - and thus I should have made it easier for end-users to know the pref - so I will do that.

---

As for an end-user not updating and possibly putting themselves at risk - that's the end-user's problem, not my fucking problem - there's some responsibilty on the end-user's side: on our side, earthlng already does nice changlogs for users etc. And on the responsibility thing: I have always tried to consider everyone's needs, and walk a mile in their shoes: and to always make sure no-one is disadvantaged or ever put at risk by default. It's complicated and involves the audience level. I'll never please everyone. But I personally go to extraordinary lengths for every decision I make, because I would like to think I am responsible, so your words are a little hurtful, sorry.

And by it's very nature, the permutations of what can be achieved with so many prefs is astronomical - and things are going to break. Hence it's always been a TEMPLATE with what has morphed from a more hardened default to a more balanced one.

This is a template, and users are expected to override stuff when it doesn't suit their needs/wants.

True. Especially new users (and I will add LB'ing to the wiki etc), but there's no easy answer for existing users as we make changes or add new ones: The only way is for them to:

• update and find breakage and either work it out themselves or come back here etc
• read the changelogs etc

I think part of the "agreement" of using this user.js, is that as an end-user, its up to you to keep up to date with what we do: not the other way round. No one forced you to use this. And to call a visual change as irresponsible and to say I put you at risk is just plain wrong. But I do get the point that it's a kind of a WTF moment when it happens.

This is a very invasive change similar to disabling javascript

This is not a helpful comparison at all.

[Thorin-Oakenpants]

Without wanting to rehash everything

Sheeshus .. that was a total failure :man_facepalming:

[GIPeon]

If my 2c can have any weight on this I'd suggest to place a disclaimer in the main readme.md.

This one you "rehashed" is more than fine, even a bit too gentle with the end user IMO, being this an obvious RTFM* issue.

All you guys are doing is way more than any user (I'd say anybody) should even expect.
Anyone pretending or pointing out problems like this should be gently directed to the disclaimer section.

* Please note I don't want to use this in any harsh way, is just a convenient and succint slang.

[claustromaniac]

Anyone pretending or pointing out problems like this should be gently directed to the disclaimer section.

When it comes to disclaimers, I'd say the MIT license should be good enough for all cases (seriously, it's THE disclaimer), but, personally, I prefer to try and reason with others, and discuss the stuff. At least as long as I'm not too busy/tired, but I can always postpone it if that's the case anyway.

I think a more specific disclaimer in the form of guidelines for opening issues could be useful though, because it wouldn't clutter the readme. Maybe. Perhaps. Just letting my fingers type what I'm thinking right now.

[GIPeon]

I think a more specific disclaimer in the form of guidelines for opening issues could be useful though

This is even better, it would be a prompt and active reminder for anybody instead of hoping they will read thoroughly the main readme page and the wikis. It's a fairly common structure in lots of projects too.

[claustromaniac]

That's me like... 23 hours a day.

[claustromaniac]

I went ahead and wrote some template prototypes in my fork (for previewing etc). Check them out..

There's room for improvements but, If you like them, I'll submit a PR.

[claustromaniac]

Done!

[Thorin-Oakenpants]

I'm considering this closed.

• I have added a setup tag and linked 4501 & 4504 to each other
• I have modified the wiki implementation page and even used a new icon :eyes: to make this stand out
• I have also added a prominent foreword on the 67 changelog
• :cat2: has created issue templates which place the bulk of the responsibility for problems and changes on the end-user to do their part (as long as we do ours) - thanks :cat2:

So I no longer have any sympathy for anyone who comes in here and cries about this from now on

[Thorin-Oakenpants]

FYI: https://old.reddit.com/r/FirefoxCSS/comments/c7t8cc/need_help_with_userchromecss_new_method_of/

example

#tabbrowser-tabpanels{
  background-color: rgb(46,54,69) !important;
}

[claustromaniac]

Le 👖 always deleting comments and leaving everyone else involved in the conversation looking like nutcases... What is the deal?

I'm gonna have to start adding full quotes to all my replies just to be safe from now on :trollface:

[crssi]

Example:

/* LetterBox color */
.browserStack {
  background-color: rgb(0, 0, 0) !important;
}

...works the same way, and both have the same problem at painting new tab when set to about:blank.

[jingofett]

^^ yup, whatever works. I like Window Resizer as it automagically adds window position, and also shows you the values in a new preset if it's not set, and you can have as many as you want (AFAIK)

When setting up: go to https://arkenfox.github.io/TZP/tzp.html#screen (make sure you are at 100% zoom) and resize your browser until [css] inner window hits the desired result: e.g 1200 x 800. Then flick down the icon menu and voila - you now know exactly how much to add to width and height to get sizes: e.g in my case it is +14 for width and +110 for height

Sorry for the bump, but I cannot get it to not show the 1 pixel white lines on the bottom and top of the window without making the [css] inner window display 1200x599: Should I bump it to 1200x600 and deal with the white lines (changing the colors is possible, I believe from the last couple of posts?) But when I bump it to that the rest of the options also go up 1 pixel. My monitor size is 1920x1080 and I made my privacy window settings 1800x900

[Thorin-Oakenpants]

• You wouldn't get a 1px white line unless you were 100's + 1pixel: i.e 601 -> 1 px white line, 602 -> 1px white line top and bottom (i.e total 2 pixels), etc.
• You're using LB (letterboxing) right, i.e pref 4503 edit: 4504 = true ?
• What OS are you on, and what is your system DPI (and/or page zoom)? I ask because I find it quirky that both css is out by one pixel on the height

[jingofett]

I am using letterboxing. I am on Windows 10, but I am on 135% scaling, I guess that might be the issue. I believe my DPI is 96. I'll try fiddling with the scaling settings.

EDIT: Yup. Custom scaling screws with it for some reason. Can only use the presets (100, 125, 150)