Cannot Log In

[ioletsgo]

Expected behavior
Pressing the login button with the proper password allows you to login

Actual behavior
It stays on the login screen

Steps To Reproduce
Type Password
Press Enter
...
Press the login button
...

Additional context
Occurs on a fresh login. Might be fault of webkit2. Will update when I do further testing

WARNING:
Bug reports that do not follow this template WILL be closed immediately. Aether is developed for free, please be considerate of my time!

[ioletsgo]

Issue of webkit2 it appears. Other themes faulter from this problem

[hsalas]

I just encounter the same problem, Any suggestions on how to deal with it?

[zaggash]

Remove the latest webkit2gtk update and wait for a fix

[NikolaM-Dev]

Remove the latest webkit2gtk update and wait for a fix

How?

[hsalas]

Remove the latest webkit2gtk update and wait for a fix

How?

If you are on an Arch-based distro, a simple way of doing this is installing downgrade from the AUR. Then you can just run downgrade webkit2gtk and it will give you a list of older versions to choose from

[NikolaM-Dev]

Remove the latest webkit2gtk update and wait for a fix

How?

If you are on an Arch-based distro, a simple way of doing this is installing downgrade from the AUR. Then you can just run downgrade webkit2gtk and it will give you a list of older versions to choose from

Thank you, I also learned about a very useful tool

[ioletsgo]

I downgraded to 2.36.2-1 and it works for me. I would greatly appreciate it if somebody could alert me when this is no longer an issue

[D3vil0p3r]

Hello guys. The latest good version of webkit2gtk for Aether is the 2.36.7. I also did an investigation about this issue by giving all the analysis to the webkit2gtk devs for fixing it, but they asked me to send them a backtrack by coredumpctl gdb. The problem is that, when I tried to create a backtrace by "injecting" G_DEBUG=fatal-warnings inside the flow of execution of the LightDM, the Login Manager does not spawn, and the devs said me they won't fix until they don't receive the backtrack. It makes me to think that maybe they don't care to solve the issue because they could replicate the issue very easily but they don't want to test it, only get the backtrace. However, the issue is caused by two files: /usr/lib/libjavascriptcoregtk-4.0.so and /usr/lib/libwebkitgtk-4.0.so. So, if you take these two files from the 2.36.7 version and replace the ones of the 2.38 version, you solve the issue.

If you want to try to convince the devs to investigate or fix the issue for the next release, please contact them on matrix: https://matrix.to/#/%23webkitgtk:matrix.org

Also because, remember, if you downgrade the package, you must keep them in the ignorelist, otherwise you will break it again. I hope they can be pushed to fix this issue.
Cheers.

[zaggash]

It is not impacting only your theme.
It is all themes using webkitgtk.
Weird reaction from them

[D3vil0p3r]

It is not impacting only your theme. It is all themes using webkitgtk. Weird reaction from them

True. It is impacting all the webkitgtk-based themes. If you have the chance to do some tests by using G_DEBUG=fatal-warnings and hoping the Login Manager crashes by producing the backtrace by running sudo coredumpctl gdb, please try. So, if we get something, we can provide it to the devs.

[zaggash]

Where do you set the option G_DEBUG=fatal-warnings ?

[D3vil0p3r]

Where do you set the option G_DEBUG=fatal-warnings ?

Usually, the G_DEBUG=fatal-warnings is an environment variable that, each time you get a warning, the application crashes, and you can see the events by executing sudo coredumpctl gdb. It is applied to webkit2gtk because it uses GLib.

You can set that environment variable as global env variable in /etc/profile.d/yourscript.sh and inside this script you insert that G_DEBUG=fatal-warnings (remember that in this case, since it is a global environment variable, each component of your system generates a Warning, it crashes, and probably it will happen on GNOME. In this case, just access to TTY by CTRL+ALT+F2 and remove that yourscript.sh.

Another safer way is to define G_DEBUG only for the context of the running processes. For doing this, since LightDM calls several processes and the one that should create this issue is the WebKitWebProcess, you can create a exe file or a bash script that should be called by the parent process that is currently calling the WebKitWebProcess. And this new exe or script will have inside it G_DEBUG=fatal-warnings and also the call to WebKitWebProcess. This process is easier to do than to explain.
The problem is that, I tried all these cases but for some reasons it didn't work and I was not able to get the resulting backtrace from coredumpctl gdb.

[D3vil0p3r]

One more additional information:
The initial logs about crash directly related to our issue, but that devs don't accept, are on /var/log/lightdm/seat0-greeter.log. For accessing to it, just reboot the system, try to login, nothing occurs, press CTRL+ALT+F2, authenticate by TTY, run sudo cat /var/log/lightdm/seat0-greeter.log and you will see the output.

Inside the first Warning (that I think should be the reason the login cannot occur) is related to WebKitWebProcess.

Furthermore, this process file can be found in /usr/lib/webkit2gtk-4.0/WebKitWebProcess.

[JezerM]

@D3vil0p3r, the issue is not that the Display Manager doesn't spawn, the issue is actually that lightdm-webkit2-greeter tries to connect to the Display Manager (LightDM) through webkit2 extensions and it fails. It's not a crash, but perhaps a security limitation regarding webkit2 extensions. The solution could be to decrease this security limitation, but that falls on WebKit devs; the other solution would be to rewrite lightdm-webkit2-greeter so it connects to LightDM from the main context, instead of webkit2 extensions.

You can see more about my little research at my Litarvan's comment: Litarvan/lightdm-webkit-theme-litarvan#186 (comment)

[D3vil0p3r]

@D3vil0p3r, the issue is not that the Display Manager doesn't spawn, the issue is actually that lightdm-webkit2-greeter tries to connect to the Display Manager (LightDM) through webkit2 extensions and it fails. It's not a crash, but perhaps a security limitation regarding webkit2 extensions. The solution could be to decrease this security limitation, but that falls on WebKit devs; the other solution would be to rewrite lightdm-webkit2-greeter so it connects to LightDM from the main context, instead of webkit2 extensions.

You can see more about my little research at my Litarvan's comment: Litarvan/lightdm-webkit-theme-litarvan#186 (comment)

Why you mention that lightdm-webkit2-greeeter cannot connect to LightDM? In our case, the problem is that the Login Manager is shown, but when you insert the password and click on the arrow icon, it does not execute the login, due to ../glib/glib/giounix.c:412Error while getting flags for FD: Bad file descriptor.

[JezerM]

Exactly, that's because lightdm-webkit2-greeter cannot connect to the LightDM daemon. LightDM can show the greeter without being connected as the greeter (lightdm-webkit2-greeter) can choose when to connect; the main issue is that lightdm-webkit2-greeter fails to connect, so the greeter is shown but there is no connection, therefore it fails to log in.

[JezerM]

LightDM provides the lightdm_greeter_connect_to_daemon_sync function which allows the connection between the greeter and the Display Manager, which is failing on a webkit2 extension context. When you're not connected to the Display Manager daemon and try to authenticate or execute any of the LightDM functions, you get the following message: assertion 'priv->connected' failed, which is what you're getting here.

To summarize, lightdm-webkit2-greeter tries to connect to LightDM through a webkit2-extension context, due to possible security limitations a Bad file descriptor warning is provoked and the connection fails, consequent attempts to authenticate and start_session fails as lightdm-webkit2-greeter is not connected to LightDM. Thus, you cannot log in.

[mcatanzaro]

Only problem is lightdm-webkit2-greeter does not enable the web process sandbox, so there are no security restrictions at all. It should have full access to your host system to do whatever it wants. I've left a comment in Litarvan/lightdm-webkit-theme-litarvan#186.

[mcatanzaro]

It makes me to think that maybe they don't care to solve the issue because they could replicate the issue very easily but they don't want to test it, only get the backtrace.

Truthfully yes: I have other issues to work on that don't require installing lightdm or lightdm-webkit2-greeter, sorry.

My suspicion is that if you don't have a core dump for WebKitWebProcess in coredumpctl, then it's probably not really crashing. Maybe you need to set the environment variable for lightdm-webkit2-greeter, rather than lightdm itself?

The reason I suggested G_DEBUG=fatal-criticals is the backtrace will point you to exactly what is going wrong. That doesn't guarantee that we understand the problem, but at least that we would know exactly where the bad file descriptor is and would have some chance to debug it.

[D3vil0p3r]

It makes me to think that maybe they don't care to solve the issue because they could replicate the issue very easily but they don't want to test it, only get the backtrace.

Truthfully yes: I have other issues to work on that don't require installing lightdm or lightdm-webkit2-greeter, sorry.

My suspicion is that if you don't have a core dump for WebKitWebProcess in coredumpctl, then it's probably not really crashing. Maybe you need to set the environment variable for lightdm-webkit2-greeter, rather than lightdm itself?

The reason I suggested G_DEBUG=fatal-criticals is the backtrace will point you to exactly what is going wrong. That doesn't guarantee that we understand the problem, but at least that we would know exactly where the bad file descriptor is and would have some chance to debug it.

Sorry mate. Like you, we also have other priorities and this issue could be easily managed by downgrading webkit2gtk as reported above. For this reason, if we report this, it is mainly for the devs, not mainly for us, in order that all users could have a consistent new release. I can continue to do these tests but, I mean, doing this "at best effort" together could be a good way, but I wouldn't ignore the problem. Of course I'll consider what @JezerM reported.

[mcatanzaro]

Moved to https://bugs.webkit.org/show_bug.cgi?id=246206