@mark-monteiro Did you mean macOS?

So I missed this entirely.

Right now the Windows and macOS tray/wrappers are not as fancy as you might think. At their heart, they launch/stop a Jellyfin process running in the background. They do have some options on what arguments to start the server with (like --noautorunwebapp) depending on user settings.

With this change, things become more difficult. How do I know when the server is finished startup? It's not just as easy as launching it right after the server process, because I could be too early/fast. I might end up with a "localhost not found". Even if I check for a page, the server does have its own "Server is loading, please wait…" page before it's ready. I imagine in some complex environments, this page may be up longer than 1 or 2 seconds, so a delayed browser start won't work reliably (and might make the user feel like Jellyfin isn't working, but I suppose that already happens).

This will of course add more code to the wrappers as well. I know the Windows one is just some more C#/.NET work, but since I can barely hack together the macOS one, it'll likely stay as a manual browser launch there for the foreseeable future.

I should note - both wrappers already have a menu item to launch the web UI. It just kicks to the shell and says "open this URL with your default browser". So that functionality is there at least.

I guess the concerns come with:

• first time setup
• whether or not this is a behaviour people expect (need to check how Emby and Plex do this)

@anthonylavado yes, macOS. This came up as a suggestion as a result of a code review with @Bond-009 and @dkanada, so maybe they have some other ideas. But I agree that at the very least we need to check whether our console users would prefer to have this functionality removed, or the default changed to not launch the app.

Talking to @Bond-009 in chat, I'll make it just not automatically launch the web UI for now, and users can open it with the menu item if needed. This will still suck for first time setup though.

Here's a potential solution: Replace the "server is loading..." message with a proper HTML page response that has a very basic loading page. The page can include some basic styling and a small amount of JavaScript to ping the server and refresh the page when it is ready.

Then the client wrappers should be safe to open up a browser immediately and users will also get an even better loading experience than we have now.

Anyone in @jellyfin/backend see issues with the proposed solution in my comment above? If I get some thumbs up I'll remove the discussion needed tag. This could be a good task for one of the newer devs to pick up, I think it's a relatively isolated piece of functionality

I am fine with that page. It makes sense for other use cases as well.

Okay, the issue description is updated with the new approach and I've updated the labels again. Maybe a bit of a stretch now for the good first issue label but I've tried to add as much detail as possible to make it easier :)

If there's any holes in the approach or description let me know and I can update

I have no idea if I should have ever started to tackle this issue as my first ever, but I thought I should at least try after I saw the "good first issue" label. I am deeply sorry if this created any inconvenience for anyone.

About removing the logic of auto-launching browser, as far as I understand after the building is complete browser should not be started at all? Or does it mean that browser should not be started from the server? I did edit the StartupWizard.cs and BrowserLauncher.cs, but after the build browser still opened up with the main page of Jellyfin. I am building nowebclient version.

Thanks in advance!

@avokado1337 Yes, we don't want the server to launch the browser at on normal startup. If nothing has changed since I made this issue, this functionality can be removed by updating StartupWizard and BrowserLauncher (as you mentioned you did already).

However, when running from an IDE (Visual Studio, or VS Code), we do want the browser to launch after building, for convenience for developers. In Visual Studio this is controlled by the IDE settings file launchsettings.json (there is similar functionality for VS Code, but I am not familiar with it).

Maybe your browser is still being launched by the IDE and not the server code?