[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-talk] loading some content changes Tor Browser 9.0 to full screen
On 11/19/19 2:53 PM, Matthew Finkel wrote:
Sorry for the delay, thanks for your questions.
On Tue, Nov 5, 2019 at 9:16 AM Joe <joebtfsplk@xxxxxxx> wrote:
In TBB 9.0, should about:config "full-screen-api.enabled" be "true?"
It is =true by default, in my auto-updated TBB 9.0, in Linux Mint.
No problem. Thanks for the info.
I haven't yet tried to see checked what screen size is reported, e.g.,
to EFF or browserspy.dk, etc., when a site (or content on it) requests
full screen. Of course, I had to force full screen, then reload the
sites. I'm not sure that gives same result as a site / content causing
**What all prefs need changing to prevent ever going full screen?
Info Matthew pasted:
"Note that requests for fullscreen inside a web app's origin are exempt
from this restriction", and "Only grant fullscreen requests if this is called from inside a trusted
event handler (i.e. inside an event handler for a *user initiated* event)"
In this context, what does "inside a web app's origin" mean?
Instances of going full screen weren't common - but were random.
As far as "grant fullscreen...for a user initiated event," yes, I
clicked on links, but not 3rd party links or showed in status bar it was
from a different domain. That's a strange way of putting it - "user
Without examining the page source in detail (most won't understand it)
users don't know or expect that clicking a random object on a site they
trust, might go full screen. If I knew that ahead of time, I wouldn't
click such objects. "User initiated" - when you ring a doorbell, you
don't expect it to spray toxic gas, though you initiated contact. I'm
not knowingly "giving consent" to anything to force full screen - it's
not the norm.
Testing TBB 9.0.1, when I force full screen (F11), then reverse it, TBB
goes back to the initial "screen size" - at least on Browserspy.dk. It
displays blank white space / bands around the screen (NOT the same width
on L, R & bottom). It also uses UP some of the available screen size -
with black bars on L & R of the screen.
The overall screen width detected, INCLUDING wide black bands is a
multiple of 200px, but I'm guessing an interested site could detect the
size that will display content.
After exiting full screen, the width that actually displays content is
an odd w=909 x h=900px, where 2 seconds before going full screen, the
detected size displaying content was 1000px W x 900px H.
So it's not just a matter of detecting real screen size. It gives them
an odd value in a specific case.
If they can back calculate the vertical scrollbar width by using given
sized images, I don't see why they couldn't calculate the "usable"
screen width (screen width minus black bands).
Disabling fullscreen is not a good solution.
It might be if users were simply asked / warned *before* screen size change.
It is if you don't want random sites or content - unexpectedly - causing
full screen & on exiting full screen, the usable display area is no
longer even multiples of 200 x 100.
They warn on accidentally changing the screen by 2px, but don't prevent
or warn BEFORE a change happens. The warning process needs to prevent
size change, until users confirm the change.
My screen size changes are all accidental or from not being warned that
some content is asking for full screen mode.
We have another ticket, where the user is prompted before fullscreen is allowed, for that:
That ticket's 5+ yrs old. It's not helping. Maybe there are much more
important issues (who runs entry / exit nodes). I will probably disable
"full-screen-api.enabled" and others.
For now, why not add a button / setting in preferences or in... so users
can disable all screen changes (allowed by prefs), until progress is
made on ticket #12979? Users not that worried about fingerprinting can
use default settings.
"full-screen-api.allow-trusted-requests-only" - there are no generally
"trusted requests" to go full screen, if you don't want to give up more
browser info. Maybe OK for checking function of your own website or such.
tor-talk mailing list - tor-talk@xxxxxxxxxxxxxxxxxxxx
To unsubscribe or change other settings go to