privacy.resistFingerprinting should not create windows with rounded dimensions when letterboxing is enabled
Categories
(Core :: Window Management, defect, P5)
Tracking
()
People
(Reporter: ke5trel, Assigned: ke5trel)
References
(Blocks 1 open bug)
Details
(Whiteboard: [fingerprinting][tor])
Attachments
(1 file)
When privacy.resistFingerprinting = true and privacy.resistFingerprinting.letterboxing = true there is no need to round window dimensions since it is already handled by the content letterboxing.
When privacy.resistFingerprinting = true and privacy.resistFingerprinting.letterboxing = true there is no need to round window dimensions since it is already handled by the content letterboxing.
|
||
Comment 2•5 years ago
|
||
It is my understanding that the letterboxing will eventually replace the chrome re-sizing, but for now is a separate pref for testing purposes
A case could also be made for to keep chrome resizing on new windows, so that all users fall into as few buckets as possible (until they manually resize, go full screen, toggle sidebars etc). I see the letterboxing as an extra, not a full replacement
|
||
Comment 3•5 years ago
|
||
I appreciate the patch! I think we don't know how we want letterboxing to behave with regards to auto-rounding window dimensions on startup. I can see arguments for both sides. Since letterboxing is currently experimental and unsupported I think we will keep this bug on file for now.
|
|
||
Comment 4•5 years ago
|
||
Some thoughts:
If this replaces the chrome-sizing on new windows
- it removes most barriers to uptake: e.g can't open maximized, desktop screens aren't using landscape, on restart dimensions aren't remembered, etc.
- I can't find the study that was done on this: it was about a year ago. From memory "display" issues were a problem for 75-80% of respondents and uptake is important to build RFP (on Firefox) numbers when this becomes front-facing.
- This would also simplify things/code, and make issues such as the toolbar density and display of icons on it, moot. See Bug 1418537 . It should also mitigate any future changes to chrome (e.g that bug shows even differences between Linux desktop environments and platforms).
- This is probably not an issue for Tor Browser since they can enforce what they like, but any changes/removal of code here would affect them
If this enhances the chrome-sizing on new windows
- There will still be usability issues; e.g allow opening maximized should be allowed (the user clearly wanted it that way). e.g the first browser instance (if not maximized) could be resized, but subsequent ones should match (i.e the end user has already manually resized the browser, and does not wish to do it to every window thereafter in this session). I can think of more cases.
The more I think about this, the more inclined I am for letterboxing to replace current RFP behavior (am I allowed to change my mind?). I am interested to hear what TB think.
PS: If anyone can find that study, let me know. It was about a bunch of RFP items. TZ spoofing was the second biggest issue from memory
|
||
Comment 5•5 years ago
|
||
I can't review this, since I have no idea what privacy.resistFingerprinting.letterboxing is supposed to control.
|
|
||
Comment 6•5 years ago
|
||
(the patch does looks reasonable from code point of view)
|
|
||
Comment 7•5 years ago
|
||
(In reply to Olli Pettay [:smaug] from comment #6)
(the patch does looks reasonable from code point of view)
I've tested everything [1] I can think of that would affect this (in the session) and only one item "breaks" it: the findbar, and I'm not sure how or if that should be handled, as it is a per tab change (or is there a pref that makes it global?) whereas the letterboxing is applied globally (AFAICT). Maybe one day we can have a floating findbar
[1] changing/installing themes which affect density etc, changing density, toggling sidebar, toolbars, menubar, manual resizing, maximizing, full-screen, and combinations of multiple tabs and various zooms.
[2] As I type, I have not changed DPI etc (am a bit loathe to on my current system)
|
||
Updated•5 years ago
|
|
|
||
Comment 8•5 years ago
|
||
Be aware that removing the new window size mechanism would result in gaining a user's max step values
|
|
||
Comment 9•5 years ago
|
||
^^ which is probably not a big deal since the full screen api can do this anyway - see Bug 1450401
|
Assignee | |
Comment 10•5 years ago
|
||
I updated the Phabricator revision with the requested change but the "Accepted" state did not reset which is a bit concerning.
If you want to land this, can someone trigger a try run for me? Thanks.
|
|
||
Updated•5 years ago
|
|
|
||
Comment 11•5 years ago
|
||
Note that we definitely don't want to do this until Bug 1556016 is fixed, as the size-a-new-window behavior coincidentally protects us from a letterboxing bypass.
|
||
Updated•2 years ago
|
|
|
||
Comment 12•4 months ago
|
||
Until Tor tells us otherwise, this is a wonfix.
Description
•