Created attachment 165499 [details] Google sign in browser window SUMMARY STEPS TO REPRODUCE 1. System Settings -> Online Accounts -> Add -> Google 2. Enter email, press next. OBSERVED RESULT Couldn’t sign you in - This browser or app may not be secure. See screenshot. Learn more leads here: https://support.google.com/accounts/answer/7675428?hl=en-US EXPECTED RESULT Password/2FA fields are shown. SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: (available in About System) KDE Plasma Version: KDE Frameworks Version: Qt Version: ADDITIONAL INFORMATION
Sorry, versions: SOFTWARE/OS VERSIONS Linux/KDE Plasma: KDE Neon Unstable (available in About System) KDE Plasma Version: 6.0.80 KDE Frameworks Version: 5.249.0 Qt Version: 6.6.1
Indeed, it looks like we're going to need to make some changes here.
Works fine for me on Fedora Rawhide. Likely has to do with signon-ui/QtWebengine, but there's no obvious difference between Fedora and Neon as far as I can tell
*** Bug 482808 has been marked as a duplicate of this bug. ***
I can reproduce this bug on my machine. Operating System: Arch Linux KDE Plasma Version: 6.0.1 KDE Frameworks Version: 6.0.0 Qt Version: 6.6.2 Kernel Version: 6.7.8-arch1-1 (64-bit) Graphics Platform: Wayland Processors: 12 × AMD Ryzen 5 5625U with Radeon Graphics Memory: 14.5 GiB of RAM Graphics Processor: AMD Radeon Graphics
Hi all, I can confirm this bug either in a HP Zbook running Plasma 6.00 and also in a virtual machine running VMWare also running Plasma 6.00. My google account is 2FA activated. If you need more details, just let me know.
I have he same issue on KDE Neon based on Ubuntu 22.04 with KDE 6 upgraded from KDE 5. Additionally, existing Google accounts do not show any files any more (the loading never stops).
Running systemsettings from the command line and trying to add a new google account I get: "google" Looking for plugin "" Starting auth session with "oauth2" Info: Id: 105 caption: "google" owner: "" userName: "" qt.dbus.integration: Could not disconnect "com.google.code.AccountsSSO.SingleSignOn.Identity" to "destroyed(QObject*)" : Pointers are not supported: QObject* This occurs in a Gentoo system with plasma-6.0.3 with qt-6.7.0
*** Bug 484741 has been marked as a duplicate of this bug. ***
*** Bug 489645 has been marked as a duplicate of this bug. ***
*** Bug 489435 has been marked as a duplicate of this bug. ***
I'm 99% sure that "qt.dbus.integration" error from post #8 is not related to the issue at hands, and in fact is just a side effect of automatic runtime method registration which was not supposed to register the pre-descruction signal.
I just tripped on this, and here's a workaround that worked for me, combined from an earlier workaround posted in #485286 and my own experimentation: 1. I maximized the embedded browser window that displays the authentication page 2. I switched the language to Polish (my language) 3. As per the original workaround (which was insufficient on its own in my case), I clicked Next with mouse instead of using Enter No further problems encountered.
*** Bug 490925 has been marked as a duplicate of this bug. ***
(In reply to Szczepan Hołyszewski from comment #13) > I just tripped on this, and here's a workaround that worked for me, combined > from an earlier workaround posted in #485286 and my own experimentation: > > 1. I maximized the embedded browser window that displays the authentication > page > 2. I switched the language to Polish (my language) > 3. As per the original workaround (which was insufficient on its own in my > case), I clicked Next with mouse instead of using Enter > > No further problems encountered. This worked for me too, although I did not change the language.
Tokens expiring in Dolphin also. Also cant add Google account in Solus Plasma 6.
(In reply to gabriel.rilling from comment #15) > (In reply to Szczepan Hołyszewski from comment #13) > > I just tripped on this, and here's a workaround that worked for me, combined > > from an earlier workaround posted in #485286 and my own experimentation: > > > > 1. I maximized the embedded browser window that displays the authentication > > page > > 2. I switched the language to Polish (my language) > > 3. As per the original workaround (which was insufficient on its own in my > > case), I clicked Next with mouse instead of using Enter > > > > No further problems encountered. > > This worked for me too, although I did not change the language. I've tried this a few times on two separate systems, I don't speak polish and even tried that part specifically but unable to reproduce today. All items give an error indicating that there is an issue with the browser used for sign or the app setup to allow sign-in.
*** Bug 485286 has been marked as a duplicate of this bug. ***
(In reply to Elvis Angelaccio from comment #18) > *** Bug 485286 has been marked as a duplicate of this bug. *** Actually, even this report really looks like a duplicate of #420280 I guess we can close this one as well?
(In reply to Elvis Angelaccio from comment #19) > (In reply to Elvis Angelaccio from comment #18) > > *** Bug 485286 has been marked as a duplicate of this bug. *** > > Actually, even this report really looks like a duplicate of #420280 > > I guess we can close this one as well? Like https://bugs.kde.org/show_bug.cgi?id=420280#c105 , I'm facing this bug on Arch with a fairly recent signon-ui version (0.17+20231016), so this may not be the same bug as #420280 which is apparently due to a too old signon-ui version.
Seconded, I am on signon-ui 0.17+20231016-2 and facing this issue.
(In reply to gabriel.rilling from comment #20) > (In reply to Elvis Angelaccio from comment #19) > > (In reply to Elvis Angelaccio from comment #18) > > > *** Bug 485286 has been marked as a duplicate of this bug. *** > > > > Actually, even this report really looks like a duplicate of #420280 > > > > I guess we can close this one as well? > > Like https://bugs.kde.org/show_bug.cgi?id=420280#c105 , I'm facing this bug > on Arch with a fairly recent signon-ui version (0.17+20231016), so this may > not be the same bug as #420280 which is apparently due to a too old > signon-ui version. Right, I'll rename this report then. Btw, I cannot reproduce on arch with signon-ui version 0.17+20231016-2
For Gentoo this bug is solved with =>signon-ui-0.15_p20231016-r2
(In reply to Szczepan Hołyszewski from comment #13) > I just tripped on this, and here's a workaround that worked for me, combined > from an earlier workaround posted in #485286 and my own experimentation: > > 1. I maximized the embedded browser window that displays the authentication > page > 2. I switched the language to Polish (my language) > 3. As per the original workaround (which was insufficient on its own in my > case), I clicked Next with mouse instead of using Enter > > No further problems encountered. Incredibly, it works. Totally nonsensical, but it works.
(In reply to Guido from comment #24) > Incredibly, it works. Totally nonsensical, but it works. Okay, this gets me further into the sign on process, where it asks me to verify my Google account on my phone, it then momentarily appears to succeed, then the embedded browser page abruptly clears and switches to say: > This app is blocked > This app tried to access sensitive info in your Google Account. To keep your account safe, Google blocked this access. When starting systemsettings from the commandline and I run through this process, I get this message: > org.kde.kaccounts.lib: Error: > org.kde.kaccounts.lib: "Access grant not present" So it seems that this can work when the embedded browser window is made full-screen (which is very weird, and no, I didn't have to change the default language). Regarding making the embedded browser full-screen, if I double-click on the titlebar, then the process will fail like it always does; I have to click the maximize button on the titlebar to have any kind of progress. Given the error "This app is blocked", maybe this issue is on Google's end?
(In reply to Michael from comment #25) > Given the error "This app is blocked", maybe this issue is on Google's end? Yeah, something about what KDE wants to do with the account is tripping some (seemingly newer?) protection on Google's end.
Ideally, KDE should use OAuth2 via the user's default browser instead of opening up an integrated browser that doesn't know any sessions.
See this interesting comment here about contents of `/usr/share/accounts/providers/kde/google.provider`: https://discuss.kde.org/t/kde-online-accounts-not-signing-in/3411/38
(In reply to Diego from comment #28) > See this interesting comment here about contents of > `/usr/share/accounts/providers/kde/google.provider`: > https://discuss.kde.org/t/kde-online-accounts-not-signing-in/3411/38 Changed provider details to those specified in the linked post used by gnome. Mine works now. It seems like the details specified in the google.provider file included by default with KDE are just invalid now.