fullscreen not exiting

[sertonix]

With most configurations the fullscreen test fails cause mozfullscreenchange is never triggered (fullscreenchange is triggered though).

When I clone the git repo and open the main test through a file:// link the test works (but not with a local http server).

I might investigate further myself but I am not sure where.

OS: alpine linux Browser: FF 125, ESR 115, FF 126 dev

[Thorin-Oakenpants]

I know. It's been on my list of things to do for about a year. Same as you, it works fine on file:// but not on HTTPS not on local server (localhost serving HTTPS) .. and I've tried to debug it but have no idea what the problem is. Even weirder, it works perfectly fine on android

maybe @PieroV can help

side note: shows just how far under the radar my work is :) that you're the first to log a bug (besides abraham about 4 years ago) and I like it that way (not the bugs, but the under the radar bit)

[Thorin-Oakenpants]

maybe @hackademix can help

all I know is i'm on my own and it's going to take me years .. will probably die before I finish

[Thorin-Oakenpants]

code if anyone cares

• https://github.com/arkenfox/TZP/blob/f02ff528a6d585a2a06474e3a73e1b7d9eefccb6/js/screen.js#L1088-L1131

[Thorin-Oakenpants]

So I already have a resize event that fires on desktops, so for desktop I will simply let the user use F11 or enter FS via click, that's it - no auto exiting. And I will do away with timer delays, which is all problematic

here's an example: FF with ~~RFP~~ letterboxing

• 

so it grabs the first measurement and keeps measuring until x time has passed (I will change this to also exit if it's stable). Timing can differ due to full-screen transition delays. Here it's approx 50ms (I think this is a reduced motion setting, not sure if RFP related). And you can see it also leaks my real screen size since it takes 50ms or so for letterboxing to kick in. In TB this is not the case since it uses css grid

You can also mouse at the top and trigger the toolbar on and off and it will also show that

I'll can also add in the difference, for example here's FF without ~~RFP~~ letterboxing

• 

as you can see the timing is approx 700ms (I round up in 50s). And the difference is going to be 85px in height which is my chrome height (toolbar + urlbar)

Basically, the user doesn't have to do anything on desktop. If you're in fullscreen it will display stuff

[Thorin-Oakenpants]

OK, so there's a big difference between click to fullscreen vs F11 .. have a play

[sertonix]

If I use F11 while the page is open the result is a bit inconsistent (1302 x 828 or 1302 x 902) and differs from the result when reload the page while staying in fullscreen ( 1300 x 900).

Any guess why?

full-screen-api.warning.timeout: 0 and ui.prefersReducedMotion: true may have something to do with it. No time to debug further right now.

OK, so there's a big difference between click to fullscreen vs F11 .. have a play

For me F11 keeps letterboxing and with the button letterboxing is bypassed.

[Thorin-Oakenpants]

so F11 (so it seems) just makes the viewport full screen, and it's still covered by LBing

• my FF with letterboxing goes -> 2560 x 1355 ▶ 2400 x 1400 [~50 ms] [diff: -160 x 45]
  • FF leaks the real value
• my TB with letterboxing goes -> 2400 x 1400 (that's it)

for either F11 (which is clearly a user thing), or a user manually enables (by clicking) the gated fullscreen API, the code does the same thing - which is measure repeatedly until it gets to a stable state. The transitions/delays/animation/stepping is dependent on settings (such as reduced motion) and some prefs only apply to one of them e.g. full-screen-api.transition* in prefs

A manual user click means a "user gesture" which enables the fullscreen API - which is used to fullscreen an element (I fullscreen the entire document) - and this is not the viewport and bypasses that

• both FF and TB leak my real screen size

I'm not sure why you get inconsistent results - you could play with a local version in file:// and just change the values

• https://github.com/arkenfox/TZP/blob/3b5408259431152b450c02e7ce4306e4f7b3c592/js/screen.js#L28-L84
• so here I'm looping up to 40 (max) times every 25 (delay) ms (after grabbing the first value immediately)
• in the checking loop or build_sizes function, I record changes only, and if I get > 5 same results in a row, I trigger the end of the loop and cause it to output: I did this to speed thing up

maybe you can comment out that > 5 line and make it always take 1000ms (40 x 25), Or you could make it 60 loops.

I have no issue here, and there should be no yank/lag since it's 25ms per check and a check here is like 0.1 ms at worst (and even the entire screen section which updates on each resize step is only a few ms - 2ms on my machine about 6ms on my 12yr old one)

that 2px too wide is a little weird but I've seen that before - but FF doesn't have borders on letterboxing, only TB does (1 pixel each side, you see). It could also be a quirk of devicePixelRatio/dpi. Here we also have 2px too tall, so this seems like the later case and absolutely not LB bordering (on FF it is anchored to the top and would only have a bottom border... and again, no borders in FF). So the 2px out reminds me of something similar in an old TB issue, but these are very hard to diagnose

The 828 height sounds like you had your mouse over the top and triggered the urlbar to drop down? You can totally do that as well. Wait for it to finish .. and then mouse over the top and wait (in F11 mode)

[Thorin-Oakenpants]

and then mouse over the top

actually that's pretty hard (impossible) to do now since it exits as soon as it can when stable (> 5 in a row) - in my earlier prototype I could record the change from one to the other as I moused up then off

[Thorin-Oakenpants]

So the original test was to manually click so TZP could use a fullscreen element to leak the real screen size. And that's now fixed and probably more robust - I might see if I can get android to use the same code (and FS the entire doc rather than an specific element) but to auto exit

The F11 results are new (i.e detecting if in FS mode and recording every step), so I don't mind if it's a little unstable for now - and we can revisit it: for example I can tell if it was the user-click vs F11 and change behavior

@pierov do you get any weird fullscreen sizes with FF11 ?

[Thorin-Oakenpants]

So I just cleaned up some logic, and use the same code for all platforms (but if android I exit FS element afterwards) - this has made android super speedy :)

So you can now F11, click fullscreen element when in F11 or already in fullscreen element, etc .. and resizing on desktop autohappens as well ... etc ... and I notate what I'm measuring. It's not not a full screen element, then I use window.inner (Width/Height), else I measure the element (clientWidth/Height)

So I used to use a image, which AFAICT didn't involve scrollbars. But by using document.documentElement this now reflects the viewport size, not the actual full screen - so I might look at using a transparent underlay or something - and this will allow me to use clientrect - so stay tuned, more changes to come at some stage

PS: and now it all works on any browser engine too

[PieroV]

On Firefox 125, GNOME I get

fullscreen	2612 x 1407 ▶ 2560 x 1440 [~750 ms] [diff: -52 x 33] [inner]

When I click F11, I can see GNOME's animation is measured.

When I click though I get 2560 x 1440.

With Mullvad Browser alpha I get

fullscreen	2612 x 1492 [fullscreenElement]

Then, if I click I get:

 fullscreen	2600 x 1400 ▶ 2400 x 1400 [~300 ms] [diff: -200 x 0] [inner]

[Thorin-Oakenpants]

I think you have the MB results back to front - fullscreenElement is when you click or are already in that state

click runs this

// initialState is if the browser is already in fullscreen, either F11 or you clicked
// which always sets window.matchMedia(q +"fullscreen)").matches) {value = "fullscreen")

Promise.all([
	document.documentElement.requestFullscreen(),
]).then(function(results){
	// if already fullscreen|android there is no resize event so call it once request fullfilled
	if (initialState == "fullscreen" || isOS == "android") {get_scr_fs_measure()}
})

display is this

let isElementFS = document.fullscreen || document.webkitIsFullscreen || false
// snip
dom.fsSize.innerHTML = size + s1 + (isElementFS ? "[fullscreenElement]" : "[inner]") + sc

document.fullscreen is only true if you clicked (and haven't escaped)

and resize events happen, and if you're in fullscreen (see initialState) it will output.

---

FF fullscreen	2612 x 1407 ▶ 2560 x 1440 [~750 ms] [diff: -52 x 33] [inner]
MB fullscreen	2600 x 1400 ▶ 2400 x 1400 [~300 ms] [diff: -200 x 0] [inner]

So when inner fires, such as if you F11 or click rerun when in F11 mode - the mode where you can mouse up and trigger the urlbar to drop down .. it measures window.innerWidth x window.innerHeight - which is not affected by scrollbars - and F11 mode usually has an transition, so we get steps (I only show the first and last and exit quickly if it seems stable)

Interesting that the sizes are well off initially, including being bigger than your screen. This is fine. Letterboxing clearly protecting us here and for both we end up at our expected results.

FF fullscreen	2560 x 1440 [fullscreenElement]
MB fullscreen	2612 x 1492 [fullscreenElement]

currently, when using a fullscreenElement - I am setting that on the document itself, and this is affected by scrollbars. So I'm going to work on using a different element (when I used an image it was not affected by scrollbars)

But ignoring scrollbars being overlays or not, this is interesting as well. I suspect the FF one was clicked after using F11 so the result was already stable. But the MB one was clicked from windowed. So this to me is a timing issue. Maybe I just need to let this mode run out the clock to get a final result.

It's definitely something I can improve, but it's not for fingerprint metrics but to test leaks - which is the original PoC - we leak on fullscreenElement

[Thorin-Oakenpants]

I had a bug in my last patch - I used to checking if steps > 1 (because I used to store the first measurement), but I don't do that anymore and only collect and count new measurements - so it should have been if steps > 0 in order

so MB fullscreen 2612 x 1492 [fullscreenElement] didn't pick the next and only step for output - or at least that's how I read it - hence it never reported the final size

I also have to use an element and not document for fullscreenElement (so scrollbars don't affect the result), and this means the screen is unreadable (because the fullscreenElement is on top) - and I can't make it transparent or anything .. and we can't leave it in that state, so I have to exit it

so all told, I split them into two separate lines

• click fullscreen only happens when you click
• F11 fullscreen happens when you are in FS including resizing triggered by F11, maximizing, manually resizing, zooming etc - so if you hit F11 you enter fullscreen and the resize triggers

I also increased the stable checks (24 in a row) before exiting, just to speed things up a little

[Thorin-Oakenpants]

windows 11: devicePixelRatio = 1, dpi = 96

FYI

FF normal
      fullscreen | 2560 x 1440
[F11] fullscreen | 2560 x 1355  ▶ 2560 x 1440  [~700 ms] [diff: 0 x 85]

FF letterboxing
      fullscreen | 2560 x 1440
[F11] fullscreen | 2560 x 1355  ▶ 2400 x 1400  [~700 ms] [diff: -160 x 45]

TB w/out letterboxing
      fullscreen | 2560 x 1440
[F11] fullscreen | 2560 x 1355  ▶ 2560 x 1440  [~600 ms] [diff: 0 x 85]

TB + letterboxing
      fullscreen | 2560 x 1440
[F11] fullscreen | 2400 x 1300  ▶ 2400 x 1400  [~250 ms] [diff: 0 x 100]

both TB + FF, regardless of letterboxing, leak your real screen size with fullscreenElement (I might rename that line) - this is a known issue, and now the PoC works as intended

But TB with letterboxing clamps/protects the F11 value whereas FF+LB doesn't - this is partly/all TB uses css grid and/or also ma1 added something to clamp the value for those precious few ms - time for ma1 to uplift all the letterboxing/betterboxing code changes

[PieroV]

leak your real screen size with fullscreenElement (I might rename that line) - this is a known issue

It's for better UX: imagine watching videos in letterboxing instead of full resolution :smile:.

Maybe it's time to bring back the permission to go fullscreen to accept first.

[Thorin-Oakenpants]

I'm not worried about the leak per se - because we can educate users to only do on a per site basis as the sole tab in that window - and we can prompt perhaps - but we also have those other issues about fullscreen API in security slider

edit: "permission to go fullscreen to accept first" - that solves the security slider issues I think so we could just do as the default

[Thorin-Oakenpants]

** imagine watching videos in letterboxing**

ever seen a 2.35:1 movie on a 16:9 widescreen tv ?