Browser Timeout: "This Screen will be closed."
-
@VGMoose I'm working on identifying the piece of code that tells the console to leave everything running.
happens to me to if there a way to stop this plz let me know
-
@Elizabeth said in Browser Timeout: "This Screen will be closed.":
Its closes on me in 20mins its quite a annoyance I wish it didnt though :(
its super annoying when trying to hold a conversation or roleplay
who dares underestimate highway trucks? i dont, its the path, not the truck, brains over brawns are the way
-
@Elizabeth said in Browser Timeout: "This Screen will be closed.":
Its closes on me in 20mins its quite a annoyance I wish it didnt though :(
its super annoying when trying to hold a conversation or roleplay
-
happens to me to if there a way to stop this plz let me know
very annoying
-
noice :D
-
EDIT for Feb 3rd, 2024:
The summary of this thread's findings is:
- This notification will appear after 20 minutes of screen-on time using the browser
- The browser will always immediately close after the pop-up
- Nintendo has ignored so far the petition asking them to enable the browser
Tips:
- If you lock the device, you can stretch the total time you have out longer
- If you launch the YouTube app, and access the DNS that way, it will automatically re-display the browser after timeout happens
- You can add top sites and bookmarks to Switchbru for faster access
About the browser:
- The timer is built-into the Switch, and enforced by the Switch's OS
- The browser itself is called NetFront, and is made by ACCESS Co
- It's possible that there is a deal between Nintendo and ACCESS that limits the usage of the browser (This is only speculation)
Homebrew workaround:
- If you have a Switch that can run homebrew, then the browser can be accessed with BrowseNX, which bypasses the timeout and allows video content
- Configuring homebrew however is much more involved than just using the DNS, and should only be done by advanced and/or technical users
Original post:
This is a thread to talk about the browser closing on the Nintendo switch when using BrowseDNS or Switchbru DNS... This appears to be a timeout added by Nintendo in FW update 10.0, but the mechanisms of when/why it closes are not known.
In my experience, I have had both web pages live for a long time (even overnight!) by sleeping the switch or pressing home, and when it decides to close always seems a little random.
It seems like no matter how many page loads occur, or clicks/scrolls I make, it's determined to shut down. Does anyone have any other experiences or theories about whne it decides to close?
If the timeout can be better understood, then we may be able to discover a workaround to it. If it's something networking related, for instance, maybe there are changes that can be made to prevent it from closing.
It would also be interesting to know if this same timeout occurs when using "normal" captive portal airplane/hotel hotspots (which is what the browser applet was made for).
I will also again plug the petition to Nintendo to unlimited this browser, including removing the timeout.
-
@Gorzog oh wow that's very useful! Thanks! I didn't realize the timeout was so precisely at 20 minutes. This is for 45.55.142.122? It would be nice if there was some networking-level thing that could be done to stretch it out longer.
When I sleep my Switch while in the browser, I am able to get a single page to last for multiple days, but maybe that is due to the total time not yet exceeding 20 minutes. I'll need to get some specific data too.
-
I managed to get it to stay on the 'This screen will now be closed' thing for a day in sleep mode.
-
@Gorzog oh wow that's very useful! Thanks! I didn't realize the timeout was so precisely at 20 minutes. This is for 45.55.142.122? It would be nice if there was some networking-level thing that could be done to stretch it out longer.
When I sleep my Switch while in the browser, I am able to get a single page to last for multiple days, but maybe that is due to the total time not yet exceeding 20 minutes. I'll need to get some specific data too.
-
so i think the sleep process just interrupts the count down , would be worth trying the timed period with a break in sleep mode to determine if the countdown continues where it left off...
so like 10 mins browsing then go to sleep then wake it up and continue the count to see if its the same.
-
so i think the sleep process just interrupts the count down , would be worth trying the timed period with a break in sleep mode to determine if the countdown continues where it left off...
so like 10 mins browsing then go to sleep then wake it up and continue the count to see if its the same.
-
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.txtHere 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.
