Plugin won't load:
_init@/usr/share/gnome-shell/extensions/[email protected]/service/plugins/notification.js:77:9
loadPlugin@/usr/share/gnome-shell/extensions/[email protected]/service/device.js:783:26
loadPlugins@/usr/share/gnome-shell/extensions/[email protected]/service/device.js:808:19
async*vfunc_startup/<@/usr/share/gnome-shell/extensions/[email protected]/service/daemon.js:746:13
vfunc_startup@/usr/share/gnome-shell/extensions/[email protected]/service/daemon.js:743:9
_init@/usr/share/gnome-shell/extensions/[email protected]/service/daemon.js:97:9
@/usr/share/gnome-shell/extensions/[email protected]/service/daemon.js:863:2
What version of GNOME Shell are you running?
Same here, fedora 29, gnome-shell 3.30.1.1
Does the remote device not support notifications? I'm confused why this would happen.
Solves the problem for me, thx!
I'm using that ZIP on Ubuntu 18.10, and this same problem occurs for me as well. I'm on GNOME 3.30.1
You're using the Zip posted in this thread? If so, what has the error message changed to?
What version of GNOME Shell are you running?
3.30.1 here running on Manjaro.
Zip solved the issue on Ubuntu 18.10 gnome 3.30.1 Tnx.
No change in error message. I'll try rebooting and reninstalling the plugin.
After rebooting and reinstalling the extension, it no longer gives me the error message, and it works on my device now :smile:
It worked for me on Ubuntu 18.04.1 LTS and Gnome 3.28.2
The correct link for the "Install from Zip" section is https://github.com/andyholmes/gnome-shell-extension-gsconnect/wiki/Installation#install-from-zip
Thanks, I forgot I moved that some days ago.
Had this the first time, it seems to all be working fine now.
Same problem happened for me when updated to the latest "Gnome Extensions" provided version. Same problem happened on both (two different computers):
(Per @andyholmes , that referenced commit 41c96a5 is the fix for this issue, the one included in the zip file above.)
Is there a way to revert the gnome extension notification? I just clicked this too now, and got this message. Or indeed release the new version with the fix :)
Confirmed, running on Ubuntu 18.04 LTS.
I updated from 12 to 13, and then it was done.
Is there a way to revert the gnome extension notification? I just clicked this too now, and got this message. Or indeed release the new version with the fix :)
I was planning on waiting until v13 was reviewed to make it easier on the reviewers, but after upgrading my distribution I forgot to re-install my email client and didn't see it was already reviewed!
I now have a million e-mails to sort/prioritize, and some unpolished changes to clean up before release, but I'll try and get this out ASAP for you all!
This turned out to have been a one-time failure, at least on Fedora 28 — when I upgraded to v13 via extensions.gnome.org, I hit the reported error (and GSConnect was non-functional), but following a system reboot v13 is working fine for me again.
This happened to me too after upgrading to v13. Wasn't the fix supposed to have been included in the latest release?
This happened to me too after upgrading to v13. Wasn't the fix supposed to have been included in the latest release?
I don't _believe_ so. My understanding of the timeline is that v13 was where people first encountered the bug. The fix will be part of v14 which hasn't been released yet.
Correct, this is fixed in the Zip above but not v13. I'm still not sure why this happens, possibly some weird race condition, but most users have reported it's fixed after a single restart of the service anyways.
Ok, that's great, thank you!
Something just occurred to me, though.
The only people who've tried the zip, AFAIK, are ones who'd already installed v13, and were replacing it with the zip. But now we know that v13 would've started working for them _anyway_, after sufficient reset. (Whether that means restarting Gnome Shell, logging out/in, restarting the system... isn't entirely clear.)
So, how sure are we that the zip actually fixes the upgrade path from v12, since that's when this bug appears most likely (or exclusively?) to manifest itself? (In fact, the real question is whether it fixes OTA upgrades via e.g.o., specifically. Which is maybe even harder to test.)
So, how sure are we that the zip actually fixes the upgrade path from v12, since that's when this bug appears most likely (or exclusively?) to manifest itself?
I believe it should be fixed. The offending bit was here, and I believe the exact error was lookup_action() returning null causing the binding to fail:
The reason why this is confusing to me, is that everything in the super._init() call is synchronous, so there's no reason the GActions shouldn't be setup at that point. I'm guessing maybe the outgoingCapabilities/incomingCapabilities are somehow partially or not populated at that time for new devices? It's a mystery, but binding to an action that way was kind of a weird thing to do anyways.
It was the _tiniest_ bit more efficient, because with the action disabled the GAction::activate signal won't trigger avoiding an unnecessary global lock, but this in the range of single-digit milliseconds. Now it just invokes the action and bails at the beginning of the sendNotification function.
Maybe it's worth submitting a v14 to e.g.o with _just_ that fix, though, to get the upgrade path corrected for people, and confirm the fix is successful. Then the next release can be v15, and contain all the substantive changes that have been made since, without having to worry about this issue. (Presumably, also, a 7-line change could be fast-tracked, relative to the time it'll probably take to get all of the v15 changes reviewed.)
(In fact, if we were going to do that, I'd even happily downgrade to v12 temporarily, to play guinea pig for the v14 upgrade.)
+1 for the Idea to release v14 with just that fix and as soon as possible.
I was with a broken gsconnect because of gnome 3.30 and had to wait for the v14 just so that i'm now with a broken gsconnect and have to wait for v14. On the user side thats really frustrating.
_init@/home/fabian/.local/share/gnome-shell/extensions/[email protected]/service/plugins/notification.js:77:9
loadPlugin@/home/fabian/.local/share/gnome-shell/extensions/[email protected]/service/device.js:783:26
loadPlugins@/home/fabian/.local/share/gnome-shell/extensions/[email protected]/service/device.js:808:19
async*vfunc_startup/<@/home/fabian/.local/share/gnome-shell/extensions/[email protected]/service/daemon.js:747:13
vfunc_startup@/home/fabian/.local/share/gnome-shell/extensions/[email protected]/service/daemon.js:744:9
_init@/home/fabian/.local/share/gnome-shell/extensions/[email protected]/service/daemon.js:97:9
@/home/fabian/.local/share/gnome-shell/extensions/[email protected]/service/daemon.js:864:2
:+1: I believe v14 has already been submitted to e.g.o with the upgrade-crasher fix.
(However, if you... well, at a maximum, completely restart your computer, you should find that v13 becomes functional. It breaks on _upgrade_ from v12, but is actually functional after that point. At least, that's been most of our experience.)
Sorry, I'm confused. Given the v13 works after the initial failure notification, what is with the rush to get v14 out?
To stop upgraders getting hit with initial failure notifications.
I updated minutes ago to a new version provided by: https://extensions.gnome.org/extension/1319/gsconnect/
I got the Error Message mentioned by this issue.
I have actually two Mobilephone connected with my PC (and they also connected together)
@ferdnyc no. After restarting it's just the same. I'm unable to use V13 at this point. Restarting does not fix it.
That would still be v13, if you got it from extensions.gnome.org. v14 with that fix is available on the releases page.
@ferdnyc no. After restarting it's just the same. I'm unable to use V13 at this point. Restarting does not fix it.
Apologies @Tids , dropped the ball on responding to this sooner.
This is (AFAIK) the first we're hearing of v13 still not working after a restart, so perhaps you're encountering some other (or, additional) bug. (It also means v14 may not solve this for you, anyway.)
Can you run:
journalctl --user -b -g gsconnect
("display all user journal entries since the last reboot containing 'gsconnect'"), and see if there are any error messages output when Gnome Shell tries to start the extension? The lines will be long, so you may want to add --no-pager so it'll wrap them instead of making you scroll horizontally.
That output _may_ contain personal information (though probably not, if GSConnect is failing to even start), so posting the entire contents may not be wise. Just copy-pastes of anything that looks interesting or important should be fine, at least for starters.
Closing this since v15 has been reviewed.
Most helpful comment
I was planning on waiting until v13 was reviewed to make it easier on the reviewers, but after upgrading my distribution I forgot to re-install my email client and didn't see it was already reviewed!
I now have a million e-mails to sort/prioritize, and some unpolished changes to clean up before release, but I'll try and get this out ASAP for you all!