Ending support for -no-browser and -noreactlogin

[Programmer Joe]

This topic is about command line options in the Steam client. A few advanced users add command line options to change how their Steam client works. If you haven't done so, you can safely ignore this whole subject. For people who do use command line options, and specifically -noreactlogin or -no-browser, we would like to learn what you're using them for. If something isn't working for you without these flags, please reply to this thread and let us know.

As of a recent client beta update we are ending support for the -noreactlogin and -no-browser command line options in the Steam Client. We expect these changes to be released to all Steam users sometime in January 2023. This concludes the journey of replacing an old framework that we began with Steam Chat, continued with the redesign of the Steam Library, and will continue with new features.

Removing these options

The -noreactlogin option was added during the new login UI beta as a way to flip back and forth during testing. This reverts to the old UI and has the effect of disabling login confirmations in the mobile app and QR code login.

Most users who use this option do so because there was a brief window where it was incompatible with -login, and that was not yet supported with the new UI. For those users, support for -login was restored in September.

Less than 1% of Steam users run -noreactlogin, but do not use -login. If you have some other reason for using -noreactlogin, we would love to hear from you. Please reply below and let us know why you're using this option.

An even smaller number of users run Steam with the -no-browser option. We added this option in 2015 when we were working through compatibility issues with SSE2 and SSE3. It disables the "steamwebhelper" process entirely, and with it most of the Steam UI. The store, community, and library tabs in the client stop working. Friends list and chat are disabled. By the end of the current beta period we expect essentially all of the Steam client to require browser support.

If you are a person who typically runs with -no-browser, please post below and let us know why you're using this option. We are not going to support this mode going forward, but we do want to fix any bugs that are causing you to run in this mode.

[[NA 33] Noswal]

This is now at page 76 of comments. Could someone list the pages where the work arounds are?

[Steven Seagull]

Publicado originalmente por NA 33 Noswal:

This is now at page 76 of comments. Could someone list the pages where the work arounds are?

https://steamcommunity.com/groups/stopcef/discussions

[luckz]

Publicado originalmente por NA 33 Noswal:

This is now at page 76 of comments. Could someone list the pages where the work arounds are?

I mention two in https://steamcommunity.com/discussions/forum/0/3758852249527312123/ .

[E=d.u²]

Publicado originalmente por NA 33 Noswal:

This is now at page 76 of comments. Could someone list the pages where the work arounds are?

There is no true work around.

[TS2]

Publicado originalmente por RiO:

Publicado originalmente por Liandri:

Also, the details are appreciated indeed. But the RAM is not really the issue (for me at least). I'm frankly not sure if I should worry more about lags that background CEF processes induce, or about the SSD wear that is caused by useless cache CEF tries to use.

If properly implemented, then CEF doesn't cause background lag.

Chromium pauses animations; limits timers to a granularity of once every 2 minutes; etc. etc. for web content in a non-focused tab and iirc may in fact completely halt / freeze entire tabs when the browser itself is minimized, meaning zero CPU usage until it gets a wake-up call.

In case of CEF embedded web views, it's up to the host program's developers to send the correct signals to CEF to enable that functionality to do its job.
If Valve doesn't do that - well... then that's on Valve, not on CEF.

This animation pausing occurs, but only when other windows are in focus. A similar case is found in that whenever a game is launched, the Steam Client will have its memory freed up by the game and otherwise remain suspended.

However, I have now begun to find interesting things concerning the JavaScript files in use by the Steam client. Aside from Base.js in the Tenfoot directory having extraneous spaces in the code unrelated to the ones usually found in JavaScript code, some of the other ones are minified. Minifying JavaScript is where all of the code has any extraneous lines and spaces removed so that all of it is on a single, unspaced line, yet still functions because a code parser treats it as legitimate. This is done to code where a human is not exactly expected to read it much, but a machine is going to most of the time, so as to attempt to net a small performance gain in handling it this way. However, it is both inconsistent, and may not be ideal compared to parsing unminified code.

[TS2]

Publicado originalmente por RiO:

Publicado originalmente por TS2:

The existence of Pale Moon is in conflict with the multiprocess usage sentiment. It still uses a single-process architecture due to the lead developer's belief that there is wasted overhead and other issues inherently tied to a multi-process architecture due to the nature of inter-process communication, as described here: https://forum.palemoon.org/viewtopic.php?f=26&t=17442

Mozilla and Firefox actually found a way around that using tooling developed in academia.
It'll blow your mind what it's based on:

WebAssembly.

They can take a C/C++ component, compile it to WASM, then compile the WASM back to native code and it instantly gets a memory safety sandbox par-for-the-course without needing process boundaries; is stripped of opportunity to directly call into any APIs that the sandbox doesn't directly offer as an interface; etc.
And the performance hit of the double-sandwiched cross-compile is actually still small enough that in 'talky' interface boundary situations, it outperforms multi-process sandboxing and cross-process marshalling.

https://hacks.mozilla.org/2020/02/securing-firefox-with-webassembly/
https://rlbox.dev/

They've been using it to sandbox their copy of the font shaping library Graphite they rely on for shaping some of the more complex; complicated; and not digital friendly; fonts and writing systems out there in the wild.

Pale Moon also supports WebAssembly and JIT compiling of it as well, even while retaining the single-process model. The only headaches the browser is notorious for having is whenever Google sites are parsed due to not directly supporting WebComponents yet, as well as contending with Polymer scripting.
(Pale Moon's forum userbase and the developer are also notoriously Anti-Google, as a sidenote.)

[Streuwinkel]

Did the recent updates reduce RAM usage by 100 MiB or so?

[Crashed]

Publicado originalmente por Streuwinkel:

Did the recent updates reduce RAM usage by 100 MiB or so?

Could just be the activity or lack thereof in your Client, while your OS scavenges idle memory.

[7Z7]

Hello !

I noticed yesterday that the -no-browser line was not working anymore and I found this topic. So I would like to give the reason why I was using this line even if it will never come back.

I like the Steam platform but when I play a game I don't care to have the Steam browser, store page or anything else running in the background ready to use at any time.

So I was using the -no-browser line in order to consume less Ram memory resources.

Currently Steam consumes almost 400mo against barely 40mo when I was using it with -no-browser

This is what I was using -no-browser for, to disable unnecessary elements that consume unnecessary resources when I play.

[Starfield]

Publicado originalmente por 7Z7:

Hello !

I noticed yesterday that the -no-browser line was not working anymore and I found this topic. So I would like to give the reason why I was using this line even if it will never come back.

I like the Steam platform but when I play a game I don't care to have the Steam browser, store page or anything else running in the background ready to use at any time.

So I was using the -no-browser line in order to consume less Ram memory resources.

Currently Steam consumes almost 400mo against barely 40mo when I was using it with -no-browser

This is what I was using -no-browser for, to disable unnecessary elements that consume unnecessary resources when I play.

I like you.

I would like an Minimalist Option.

[Maverynthia]

I use -no-browser to save on memory and have steam run faster and thus have more memory for games.

The alternative to this is well... not using steam at all.

[Steven Seagull]

I wonder if anyone here complaining about RAM usage has done any measurements. I mean, why do you care about RAM if the game runs fine still? Have you done any performance measurements with -no-browser and without it? No? Then why do you think that it has anything to do with your game performance?

If I was Valve, I wouldn't take these 20-30 guys seriously. Steam is using more RAM. OK, so what? It won't have an effect on your FPS or anything. If you think it does, then you are wrong. If you think you are not wrong, then prove it, come back with measurements at least...

[Liandri]

Publicado originalmente por Steven Seagull:

I wonder if anyone here complaining about RAM usage has done any measurements. I mean, why do you care about RAM if the game runs fine still? Have you done any performance measurements with -no-browser and without it? No? Then why do you think that it has anything to do with your game performance?

If I was Valve, I wouldn't take these 20-30 guys seriously. Steam is using more RAM. OK, so what? It won't have an effect on your FPS or anything. If you think it does, then you are wrong. If you think you are not wrong, then prove it, come back with measurements at least...

There are reports above about how some people literally can't play a game anymore, I guess this is because it can't allocate enough RAM while Steam Web helpers are using enough of it for it to become a problem.

[Duke M]

@Steven Seagull
It is an overhead which isn't needed to run or manage games, it's a markting tool which needs some resources, and at some point "some more resources" will bring a system to its limits, you don't need an analysis to understand that.

Edit: The whole concept of reserving memory infront is meant for browsers (or huge databases, and no, having 1000+ games in the library aren't a huge db) which access different websites at the same time and want to optimize milliseconds for the user which switches between them. The steam-client has access to the steam-store and the steam-community, that's nothing.

[Steven Seagull]

Publicado originalmente por Duke M:

@Steven Seagull
It is an overhead which isn't needed to run or manage games, it's a markting tool which needs some resources, and at some point "some resources" will bring a system closer to its limits, you don't need an analysis to understand that.

But this is not that simple. The OS is just paging out most of the memory to disk, so it won't take away anything from your game. What you see in task manager doesn't mean much.