Update launcher to 928

[SystemlessDev]

This also involves removing java 11 as a dependency since the launcher now handles java itself.

Screenshot of it actually working! :)

[flathubbot]

Started test build 51977

[flathubbot]

Build 51977 successful To test this build, install it from the testing repository:

flatpak install --user https://dl.flathub.org/build-repo/49982/com.mojang.Minecraft.flatpakref

[AsciiWolf]

Cool, thanks a lot! Let's just hope Mojang won't remove the -w or somehow change its behavior again in future releases.

Any chance you could also fix the version-pattern in x-checker-data? Thanks!

[SystemlessDev]

Cool, thanks a lot! Let's just hope Mojang won't remove the -w or somehow change its behavior again in future releases.

We can only cross our fingers🤞 It is listed in the help menu for the launcher so we should be in the clear.

Any chance you could also fix the version-pattern in x-checker-data? Thanks!

I'll try!

By the way, we can probably replace the "minecraft" file with:

Yeah I considered doing that but didn't know if that was something you'd want to do or not

[AsciiWolf]

By the way, we can probably replace the "minecraft" file with:

                {
                    "type": "script",
                    "commands": [
                        "exec /app/extra/minecraft-launcher/minecraft-launcher $@ -w=$XDG_DATA_HOME/minecraft"
                    ],
                    "dest-filename": "minecraft"
                },

[AsciiWolf]

So, I have just found out that the -w switch unfortunately does not seem to work. :-( Here is a $XDG_DATA_HOME directory content from inside the Flatpak:

$ ls -la $XDG_DATA_HOME
total 0
drwxr-xr-x 1 asciiwolf asciiwolf  0 Jun 27 16:30 .
drwxr-xr-x 1 asciiwolf asciiwolf 62 Jun 27 16:30 ..

It's empty.

The actual files seem to be in ~/.var/app/com.mojang.Minecraft/.minecraft.

[AsciiWolf]

And --workdir causes the launcher to crash with: FATAL:gpu_data_manager_impl_private.cc(445)] GPU process isn't usable. Goodbye.

But what is really weird, when I first launch /app/extra/minecraft-launcher/minecraft-launcher (without any switches), then with /app/extra/minecraft-launcher/minecraft-launcher --workdir=$XDG_DATA_HOME/minecraft, it does not crash. Probably because the --workdir switch is also broken and the launcher is still searching for some of its files in ~/.minecraft.

I think we would need to wait for Mojang to come with a proper fix. :-/

[SystemlessDev]

I couldn't reproduce the crash on my side but oh well.

I however don't see the issue with minecraft dumping its file in ~/.var/app/com.mojang.Minecraft/.minecraft? The version that is currently on the repo does it as well?

[flathubbot]

Started test build 51983

[SystemlessDev]

implemented the requested changes nonetheless

[flathubbot]

Build 51983 successful To test this build, install it from the testing repository:

flatpak install --user https://dl.flathub.org/build-repo/49988/com.mojang.Minecraft.flatpakref

[AsciiWolf]

I couldn't reproduce the crash on my side but oh well.

Did you try removing ~/.var/app/com.mojang.Minecraft/.minecraft first?

I however don't see the issue with minecraft dumping its file in ~/.var/app/com.mojang.Minecraft/.minecraft? The version that is currently on the repo does it as well?

No, it doesn't. That's what the --workDir switch is for. It changes the working directory to a custom (in our case XDG compliant) one. The default non-XDG directory had some issues, especially with mods. See the original PR: #20

[SystemlessDev]

I couldn't reproduce the crash on my side but oh well.

Did you try removing ~/.var/app/com.mojang.Minecraft/.minecraft first?

I indeed did

I however don't see the issue with minecraft dumping its file in ~/.var/app/com.mojang.Minecraft/.minecraft? The version that is currently on the repo does it as well?

No, it doesn't. That's what the --workDir switch is for. It changes the working directory to a custom (in our case XDG compliant) one. The default non-XDG directory had some issues, especially with mods. See the original PR: #20

I've never seen any mods nor modloaders freak out due to the Minecraft folder being at a unexpected location? Do you have any examples of said mods?

[AsciiWolf]

Anyway, if Mojang won't be willing to fix --workDir, we would have to switch back to using non-XDG (~/.var/app/com.mojang.Minecraft/.minecraft) directory. It will require re-adding a script with migration steps in it (the same as before, just opposite). And #2 and other affected tickets would have to be re-opened.

edit: The path here will have to be changed.

[AsciiWolf]

Did you try removing ~/.var/app/com.mojang.Minecraft/.minecraft first?

I indeed did

Hmm, that's strange. It always crashes for me.

I've never seen any mods nor modloaders freak out due to the Minecraft folder being at a unexpected location? Do you have any examples of said mods?

I don't remember any examples (except #2), but I remember that there were some. You can try searching the closed issues.

[nanonyme]

Would --persist and adding symlink from non-xdg path to xdg path work?

[SystemlessDev]

I've never seen any mods nor modloaders freak out due to the Minecraft folder being at a unexpected location? Do you have any examples of said mods?

I don't remember any examples (except #2), but I remember that there were some. You can try searching the closed issues.

After doing some research in the mc source code it seems like these issues are related to the launcher not handing off the path correctly. Classic mojang code

Would --persist and adding symlink from non-xdg path to xdg path work?

This was what I was about to suggest. I don't think we should wait for mojang to fix their stuff considering the fact that they're known to not fix issues like this. A symlink should do the trick to fix any weird issues related to the launcher. While not being the most optimal solution it is the best one we got unless we want to stay on a older version of the launcher. And I personally don't want that considering the fact that things like the automatic java handling isn't there.

But in the end this is up to @AsciiWolf to decide.

[AsciiWolf]

Would --persist and adding symlink from non-xdg path to xdg path work?

It won't work for existing installations that already have their files in the xdg path.

[SystemlessDev]

So what's the plan in that case? Migrate back to the non-xdg path?

[vchernin]

For existing installations I think migrating the files currently in the xdg path to the non-xdg path makes sense. As mentioned the previous non-xdg > xdg script just needs to be reversed.

If that's done I don't see why there'd be problems with a symlink pointing the xdg path to the non-xdg path.

[AsciiWolf]

So, I was thinking about how to solve this issue. Instead of waiting on Mojang devs that are not able to fix this (hello @peterix), the easiest possible solution will be to:

• Remove -w=$XDG_DATA_HOME/minecraft from the launcher launch options.

• Re-add migration script that:

1. Checks whether the $XDG_DATA_HOME/minecraft exists and does not contain .nonxdg-migrated (for example).
2. If both these conditions are true, moves the content to ~/.minecraft (inside Flatpak, so ~/.var/app/com.mojang.Minecraft/.minecraft) and creates an empty .nonxdg-migrated file inside the migrated directory. Then removes the empty $XDG_DATA_HOME/minecraft directory.
3. If $XDG_DATA_HOME/minecraft does not exist (it was removed in previous step), creates a symlink from ~/.minecraft to $XDG_DATA_HOME/minecraft (this would not fix issues like #2, so that ticket will have to be re-opened after this is merged, but will make our approach a more future-proof).

@gasinvein @SystemlessDev What do you folks think? Does this look like a good solution to you?

[AsciiWolf]

Also, I would be really happy if anyone could help me co-maintain the Minecraft Flatpak. I am too busy with many other projects I work on and also many real-life things. Sadly, I seem to be the only one active Minecraft Flatpak maintainer. :-/

If you are interested in co-maintaining this Flatpak, please let me know here. Thanks!

[flathubbot]

Started test build 53034

[flathubbot]

Build 53034 successful To test this build, install it from the testing repository:

flatpak install --user https://dl.flathub.org/build-repo/50989/com.mojang.Minecraft.flatpakref

[SystemlessDev]

* Remove `-w=$XDG_DATA_HOME/minecraft` from the launcher launch options.

* Re-add migration script that:

1. Checks whether the `$XDG_DATA_HOME/minecraft` exists and does not contain `.nonxdg-migrated` (for example).

2. If both these conditions are true, moves the content to `~/.minecraft` (inside Flatpak, so `~/.var/app/com.mojang.Minecraft/.minecraft`) and creates an empty `.nonxdg-migrated` file inside the migrated directory.

3. Removes the empty `$XDG_DATA_HOME/minecraft` directory and creates a symlink from `~/.minecraft` to `$XDG_DATA_HOME/minecraft` (this would not fix issues like ["Open resource pack folder" button does not work #2](https://github.com/flathub/com.mojang.Minecraft/issues/2), so that ticket will have to be re-opened after this is merged, but will make our approach a more future-proof).

So what you pretty much want to do is revert the migration from before? It's a solution, but I'm not sure if it's a solution we really want. I'll cook up said script though for the sake of hopefully fixing this issue however

[vchernin]

Given it means we wouldn't be reliant on Mojang maintaining the --workDir argument I think it makes sense.

I'm curious why #2 wouldn't be solved with a symlink? Instead maybe there's a way of intercepting Minecraft's open resource pack directory request?

[SystemlessDev]

I'm curious why #2 wouldn't be solved with a symlink? Instead maybe there's a way of intercepting Minecraft's open resource pack directory request?

Seems like a symlink isn't even needed!

So my idea is pretty much migrating back to .minecraft and then giving the launcher this arg -w $XDG_DATA_HOME/../.minecraft, meanwhile also putting --persist=.minecraft in finish-args.

This makes it so that the launcher actually starts since I can grab CEF from where it expects it to be (~/.minecraft), and also lets us f.ex. open the resourcepack folder ingame.

Would this be a accepted solution?

[vchernin]

I think so, hopefully the crashes discussed above don't occur.

So would this mean in effect everything important (for the user) is still in ~/.minecraft?

[SystemlessDev]

I think so, hopefully the crashes discussed above don't occur.

The crashes above was caused by the launcher trying to read CEF from ~/.minecraft even though it was supposed to read it from somewhere else (the workdir). This is solved now since we're redirecting read/writes to ~/.minecraft to .var/app/com.mojang.Minecraft/.minecraft via --persist=.minecraft.

The issue with the game not opening the resourcepack folder was caused by the game trying to open ~/.minecraft with the system filemanager even though it doesn't really exist. The --workDir argument still does the trick with telling the game where its things actually are (.var/app/com.mojang.Minecraft/.minecraft).

So would this mean in effect everything important (for the user) is still in ~/.minecraft?

The only difference for the user is that the folder is now back in .var/app/com.mojang.Minecraft/.minecraft.

[SystemlessDev]

For the record in case someone gets this issue from a fresh install.

This is MCL-18214. Known issue for Windows, MacOS and Linux. So it isn't related to flatpak.

Restarting the launcher solves the issue in 100% cases for me. And it only happens when I start the launcher from a fresh install.

[flathubbot]

Started test build 53108

[flathubbot]

Build 53108 successful To test this build, install it from the testing repository:

flatpak install --user https://dl.flathub.org/build-repo/51059/com.mojang.Minecraft.flatpakref

[AsciiWolf]

I'm curious why #2 wouldn't be solved with a symlink?

I don't think it will.

Seems like a symlink isn't even needed!

As I said, it is to make the current migration more future-proof - if we ever wanted to use the XDG dir again. And I would recommend making the symlink, it does no harm and can be useful in the future.

So my idea is pretty much migrating back to .minecraft and then giving the launcher this arg -w $XDG_DATA_HOME/../.minecraft, meanwhile also putting --persist=.minecraft in finish-args.

Why the -w arg? I already pointed out that it does nothing. --workdir is the same case. The only valid one is --workDir, but it is broken - that's why we are doing this migration back to non-XDG dir.

This makes it so that the launcher actually starts since I can grab CEF from where it expects it to be (~/.minecraft), and also lets us f.ex. open the resourcepack folder ingame.

Wait, does it really allows us to open the resourcepack folder from the ingame menu? Hmm, that's strange. I have tested it multiple times and in my case, the -w argument was doing nothing. Could you please retest this with --workDir instead of -w? I will also test this more further this weekend.

Anyway, for the migration script, it would be great if we could use the migration steps that I already mentioned here: https://github.com/flathub/com.mojang.Minecraft/pull/83#issuecomment-876393698 (Including the symlink.)

[SystemlessDev]

As I said, it is to make the current migration more future-proof - if we ever wanted to use the XDG dir again. And I would recommend making the symlink, it does no harm and can be useful in the future.

Oki I'll add that

Why the -w arg? I already pointed out that it does nothing. --workdir is the same case. The only valid one is --workDir, but it is broken - that's why we are doing this migration back to non-XDG dir.

Wait, does it really allows us to open the resourcepack folder from the ingame menu? Hmm, that's strange. I have tested it multiple times and in my case, the -w argument was doing nothing. Could you please retest this with --workDir instead of -w? I will also test this more further this weekend.

I used -w but it also works with --workDir. The help menu for the launcher shows both as valid.

The only reason why your launcher crashes is because it fails to read CEF. This is fixed by migrating back and using --persist.

The launcher launches minecraft with blahblah/bin/java -unimportantargs --gameDir /home/systemless/.minecraft --assetsDir /home/systemless/.minecraft/assets

This is natural for minecraft since it just assumes that ~/.minecraft is a actual dir meanwhile it actually just is a binding for flatpak. So it fails to make the file manager which is outside of flatpak open it.

However! To bypass this issue since our only issue is it failing to read CEF we could use --workDir $XDG_DATA_HOME/../.minecraft This makes the launcher hand off the actual directory to the game and because of that also makes the open resoucepack button work. --gameDir /home/systemless/.var/app/com.mojang.Minecraft/.minecraft --assetsDir /home/systemless/.var/app/com.mojang.Minecraft/data/../.minecraft/assets

Anyway, for the migration script, it would be great if we could use the migration steps that I already mentioned here: #78 (comment) (Including the symlink.)

:+1:

Do migration only if $XDG_DATA_HOME/minecraft exists.

Already done

Before migration, remove $XDG_DATA_HOME/../.minecraft if it exists.

I would much rather move it to a backup directory in case someone for some reason has things there.

Maybe somehow handle $XDG_DATA_HOME/minecraft/.migrated?

What would you want me to do about it?

[AsciiWolf]

I used -w but it also works with --workDir. The help menu for the launcher shows both as valid.

Hmm, when I tried it multiple times, -w did nothing.

The only reason why your launcher crashes is because it fails to read CEF. This is fixed by migrating back and using --persist.

Ah, that makes sense. Thanks!

The launcher launches minecraft with blahblah/bin/java -unimportantargs --gameDir /home/systemless/.minecraft --assetsDir /home/systemless/.minecraft/assets

This is natural for minecraft since it just assumes that ~/.minecraft is a actual dir meanwhile it actually just is a binding for flatpak. So it fails to make the file manager which is outside of flatpak open it.

However! To bypass this issue since our only issue is it failing to read CEF we could use --workDir $XDG_DATA_HOME/../.minecraft This makes the launcher hand off the actual directory to the game and because of that also makes the open resoucepack button work. --gameDir /home/systemless/.var/app/com.mojang.Minecraft/.minecraft --assetsDir /home/systemless/.var/app/com.mojang.Minecraft/data/../.minecraft/assets

This also makes sense, thanks!

I would much rather move it to a backup directory in case someone for some reason has things there.

Yeah, I think we could do this. But I don't want the migration script steps to be too complicated.

Maybe somehow handle $XDG_DATA_HOME/minecraft/.migrated?

What would you want me to do about it?

Probably nothing. That file does no harm (the new one will be called .nonxdg-migrated), therefore we can probably keep it.

By the way, let me know if you are interested in co-maintaining the Minecraft Flatpak (push rights to the Git repo). I would be happy if there were other active maintainers of this Flatpak, not just me. :-)

[AsciiWolf]

One more thing: I forgot that we probably would not be able to remove $XDG_DATA_HOME/../.minecraft since this dir is automatically created/bind-mounted as a persistent dir. We can check whether the dir is empty and backup its content if it is not.

[SystemlessDev]

One more thing: I forgot that we probably would not be able to remove $XDG_DATA_HOME/../.minecraft since this dir is automatically created/bind-mounted as a persistent dir. We can check whether the dir is empty and backup its content if it is not.

Oh right I forgot about that as well. I'll try to fix up the script with your suggestions. Time to put my bash skills into use :joy:

By the way, let me know if you are interested in co-maintaining the Minecraft Flatpak (push rights to the Git repo). I would be happy if there were other active maintainers of this Flatpak, not just me. :-)

I'll consider it :+1:

[flathubbot]

Started test build 53132

[flathubbot]

Build 53132 successful To test this build, install it from the testing repository:

flatpak install --user https://dl.flathub.org/build-repo/51083/com.mojang.Minecraft.flatpakref

[SystemlessDev]

To update this: I've tested the migration from the old version to the new one both on my computer, as well as on a friend's computer and it worked in both cases.

I feel like this is closing in at being possible to merge

[flathubbot]

Started test build 53139

[flathubbot]

Build 53139 successful To test this build, install it from the testing repository:

flatpak install --user https://dl.flathub.org/build-repo/51089/com.mojang.Minecraft.flatpakref

[AsciiWolf]

There are some errors in the launcher log:

[0710/195947.880840:ERROR:simple_backend_impl.cc(757)] Simple Cache Backend: wrong file structure on disk: 2 path: /home/asciiwolf/.var/app/com.mojang.Minecraft/data/../.minecraft/webcache2/Code Cache/wasm
[0710/195947.880860:ERROR:simple_backend_impl.cc(757)] Simple Cache Backend: wrong file structure on disk: 2 path: /home/asciiwolf/.var/app/com.mojang.Minecraft/data/../.minecraft/webcache2/Code Cache/js
Created browser window for reuse: 0x2000001
[0710/195947.890320:ERROR:sandbox_linux.cc(374)] InitializeSandbox() called with multiple threads in process gpu-process.
[0710/195947.903990:ERROR:simple_backend_impl.cc(757)] Simple Cache Backend: wrong file structure on disk: 2 path: /home/asciiwolf/.var/app/com.mojang.Minecraft/data/../.minecraft/webcache2/Code Cache/wasm
[0710/195947.904017:ERROR:simple_backend_impl.cc(757)] Simple Cache Backend: wrong file structure on disk: 2 path: /home/asciiwolf/.var/app/com.mojang.Minecraft/data/../.minecraft/webcache2/Code Cache/js
[0710/195947.908425:ERROR:disk_cache.cc(184)] Unable to create cache
[0710/195947.908498:ERROR:disk_cache.cc(184)] Unable to create cache
[0710/195948.192685:ERROR:simple_backend_impl.cc(757)] Simple Cache Backend: wrong file structure on disk: 2 path: /home/asciiwolf/.var/app/com.mojang.Minecraft/data/../.minecraft/webcache2/Cache
[0710/195948.192952:ERROR:simple_backend_impl.cc(757)] Simple Cache Backend: wrong file structure on disk: 2 path: /home/asciiwolf/.var/app/com.mojang.Minecraft/data/../.minecraft/webcache2/Cache
[0710/195948.193001:ERROR:disk_cache.cc(184)] Unable to create cache
[0710/195950.151888:WARNING:value_store_frontend.cc(43)] Reading mhjfbmdgcfjbbpaeojofohoefgiehjai.alarms from  failed: IO error: .../LOCK: Access denied. (ChromeMethodBFE: 15::LockFile::5)

Also, I have probably found another bug. :-/ Will do further testing and let you know...

[SystemlessDev]

There are some errors in the launcher log:

[0710/195947.880840:ERROR:simple_backend_impl.cc(757)] Simple Cache Backend: wrong file structure on disk: 2 path: /home/asciiwolf/.var/app/com.mojang.Minecraft/data/../.minecraft/webcache2/Code Cache/wasm
[0710/195947.880860:ERROR:simple_backend_impl.cc(757)] Simple Cache Backend: wrong file structure on disk: 2 path: /home/asciiwolf/.var/app/com.mojang.Minecraft/data/../.minecraft/webcache2/Code Cache/js
Created browser window for reuse: 0x2000001
[0710/195947.890320:ERROR:sandbox_linux.cc(374)] InitializeSandbox() called with multiple threads in process gpu-process.
[0710/195947.903990:ERROR:simple_backend_impl.cc(757)] Simple Cache Backend: wrong file structure on disk: 2 path: /home/asciiwolf/.var/app/com.mojang.Minecraft/data/../.minecraft/webcache2/Code Cache/wasm
[0710/195947.904017:ERROR:simple_backend_impl.cc(757)] Simple Cache Backend: wrong file structure on disk: 2 path: /home/asciiwolf/.var/app/com.mojang.Minecraft/data/../.minecraft/webcache2/Code Cache/js
[0710/195947.908425:ERROR:disk_cache.cc(184)] Unable to create cache
[0710/195947.908498:ERROR:disk_cache.cc(184)] Unable to create cache
[0710/195948.192685:ERROR:simple_backend_impl.cc(757)] Simple Cache Backend: wrong file structure on disk: 2 path: /home/asciiwolf/.var/app/com.mojang.Minecraft/data/../.minecraft/webcache2/Cache
[0710/195948.192952:ERROR:simple_backend_impl.cc(757)] Simple Cache Backend: wrong file structure on disk: 2 path: /home/asciiwolf/.var/app/com.mojang.Minecraft/data/../.minecraft/webcache2/Cache
[0710/195948.193001:ERROR:disk_cache.cc(184)] Unable to create cache
[0710/195950.151888:WARNING:value_store_frontend.cc(43)] Reading mhjfbmdgcfjbbpaeojofohoefgiehjai.alarms from  failed: IO error: .../LOCK: Access denied. (ChromeMethodBFE: 15::LockFile::5)

I noticed those as well but it doesn't matter since it doesn't break anything important for the user. They also go away sometimes for no reason.

Also, I have probably found another bug. :-/ Will do further testing and let you know...

😐

[AsciiWolf]

I noticed those as well but it doesn't matter since it doesn't break anything important for the user. They also go away sometimes for no reason.

They do not happen when there is no --workDir argument used. But yeah, they seem to be harmless, just a small bug in the launcher.

Also, I have probably found another bug. :-/ Will do further testing and let you know...

neutral_face

Yeah, and sadly, this bug is really weird. When we are migrating from already installed Minecraft profile, everything works fine. However, when we use clean, newly installed profile, and launch Minecraft for the first time, it downloads the launcher files and everything works fine to this point, but after closing the launcher and trying to launch it again, the migration process is started for some reason (and all files in .minecraft that were created when running the launcher for the first time get deleted):

Migrating back to /home/asciiwolf/.var/app/com.mojang.Minecraft/data/../.minecraft
/home/asciiwolf/.var/app/com.mojang.Minecraft/data/../.minecraft not empty. Moving away files so that we don't overwrite anything...
mv: cannot stat '/home/asciiwolf/.var/app/com.mojang.Minecraft/data/minecraft/*': No such file or directory

It does not happen anymore when running the launcher again. This is really strange...

[AsciiWolf]

Ah, nope, it isn't strange. We just probably should move the $XDG_DATA_HOME/../.minecraft/.nonxdg-migrated line at the end (after the symlink creation). ;-)

[SystemlessDev]

Also, I have probably found another bug. :-/ Will do further testing and let you know...

neutral_face

Yeah, and sadly, this bug is really weird. When we are migrating from already installed Minecraft profile, everything works fine. However, when we use clean, newly installed profile, and launch Minecraft for the first time, it downloads the launcher files and everything works fine to this point, but after closing the launcher and trying to launch it again, the migration process is started for some reason:

Migrating back to /home/asciiwolf/.var/app/com.mojang.Minecraft/data/../.minecraft
/home/asciiwolf/.var/app/com.mojang.Minecraft/data/../.minecraft not empty. Moving away files so that we don't overwrite anything...
mv: cannot stat '/home/asciiwolf/.var/app/com.mojang.Minecraft/data/minecraft/*': No such file or directory

This is really strange...

Oh I'm a moron. I forgot to move the touch command down into the other check. So if it doesn't detect data/minecraft it won't actually create that file 🤦‍♂️

Fixing it asap!

[flathubbot]

Started test build 53144

[flathubbot]

Build 53144 successful To test this build, install it from the testing repository:

flatpak install --user https://dl.flathub.org/build-repo/51094/com.mojang.Minecraft.flatpakref

[AsciiWolf]

I have found other small issue: When the launcher is started for a first time, an error is displayed instead of the main page after login and this is printed on stdout:

[0710/211419.402606:INFO:CONSOLE(2)] "TypeError: Cannot read property 'versionId' of undefined", source: mojang://launcher/static/js/app.7de005f7.bundle.js (2)
[0710/211420.963677:INFO:CONSOLE(2)] "TypeError: Cannot read property 'versionId' of undefined", source: mojang://launcher/static/js/app.7de005f7.bundle.js (2)
[0710/211444.036037:INFO:CONSOLE(2)] "TypeError: Cannot read property 'versionId' of undefined", source: mojang://launcher/static/js/app.7de005f7.bundle.js (2)
[0710/211446.191602:INFO:CONSOLE(2)] "TypeError: Cannot read property 'versionId' of undefined", source: mojang://launcher/static/js/app.7de005f7.bundle.js (2)

Everything is fine after restarting the launcher.