Browser Timeout: "This Screen will be closed."

Gorzog

@pwsincd The timeout timer when in sleep mode just pauses as you can see here

pwsincd

did u continue to time it after waking ?

Gorzog

Yes, the time that I show and on the spreadsheet is the time of 5 minutes of idling then 2 minutes of sleep mode and the rest again in idle

pwsincd

ah ok interesting info , i assuming that the timeout isn't controlled via the browser then and from the OS somewhere

pwsincd

it may be worth trying crazy ideas like on the 20minute mark or just prior keep the keyboard open or similar system processes.

Gorzog

This post is deleted!

VGMoose

I can confirm exactly 20 min on v14.0.0 as well (waking the Switch from idle each time).

I also monitored the network requests my Switch made, and here are the log files. I have the receipts!

http log: http_timeout_log.txt
dns requests: dns_timeout_log.txt

Here you can see the full 20 minute "session". Every ~1 minute a GET request is made with the user agent "NX NIFM/00".

In between those, every ~3 seconds (!!) a HEAD request is made using the full "Mozilla/5.0 (Nintendo Switch; WifiWebAuthApplet) ..." user agent (that we also see when browing web pages).

These requests are used to determine if the captive portal has been authenticated yet. In a normal flow, as soon as you agree to the terms or log into the hotel wifi, these requests would reply with a special header (X-Organization: Nintendo) which informs the Switch that it's connected to the Internet.

After exactly 20 of the GET requests, and 401 of the HEAD requests, the browser shuts, which is expected just looking at how frequently they occur (401 = (60/3)*20+1). Although it would be interesting if instead of it being a "timeout" if it were more like "try 400 times to connect every 3 seconds, then give up".

Based on this, by counting the number of requests made, it should be possible on our end to tell when the pop up is about to appear. But there still doesn't seem like there's anything that can be done on the networking side of things to interrupt it.

Also interesting is that in the DNS log, a domain name request is only made around every minute. This means in the normal workflow, depending on how the hotspot's captive portal works, it may take up to a minute to be authenticated.

VGMoose

I also tested sleep (not in those logs), the network requests just stop and resume after waking the device. (Which is why counting them to know how "soon" until the timeout seems doable.)

Elizabeth

YAY

SnowRunnerLegend

the fastest i was able to reconnect was a mere 2 seconds lol....

Koo_Hyunho

the fastestes i reconnect is like 1-3 mins ;_;

? Offline

@Akaza fastest was 30 minutes bc i went to eat a apple

Koo_Hyunho

I-

? Offline

@Akaza im sorry im the apple person of this forum

Koo_Hyunho

yesyes, I see-

SnowRunnerLegend

@applelmao said in Browser Timeout: "This Screen will be closed.":

@Akaza fastest was 30 minutes bc i went to eat a apple

pffftt

Koo_Hyunho

;_;

iggy1337

hi, this dns is good. but why videos dont play like they do when using twitter without dns, as they work fine. also webm support possible?

VGMoose

@iggy1337 I posted a new topic here about video playback: https://browsedns.net/topic/359/browser-applets-and-why-videos-don-t-work

Webm likely falls under the same boat, although I haven't tested it explicitly. There might be something clever that's doable with GIFs or HTML canvases, but there would still be no way to produce sound.

SnowRunnerLegend

-gets punched in the face by timeout- (add punch noise lol)