-
Notifications
You must be signed in to change notification settings - Fork 166
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
"Text will be here" is displayed in the tray and nothing happens by clicking on it. #459
Comments
Same issue (and setup) |
+1
OS: OpenSUSE Tumbleweed with 6.8.4 Edit: I deleted cache(and disabled and enabled extension) and it's fixed!
|
@sounddrill31 Thanks, deleting the cache and re-enabling the extension helped here as well. |
Possibly related to this? |
Can everyone here please try updating to version 62 and see if it fixes the issue for you? Thanks! 🙏 |
Thanks, it seems the issue is fixed. But faced a weird issue. i uninstalled previous one. then installed again. Got error in Gnome extension page. though the extension was downloaded. Had to log out and log in again. It seems working now. |
Thank you for testing it out @tanjilbhuiyan ! To update the extension you must log out and back in. This is true every time you update — it only updates after the next login. |
Works so far for me! Thanks for the fix |
Hello @Tudmotu, |
Thank you for confirming @sounddrill31 ! @arturo-source apologies you had to remove your cache file 😕 Hope this won't have to happen again but if it does, next time I recommend renaming the file instead of deleting it, so that you can restore it later on. |
Same here: removed the cache (was not that important anyway), so can't check. |
@Tudmotu can confirm the update to Version 62 fixed the problem for me |
Thanks everyone, closing this issue 🙂 |
This is still present here. Extension version 62. Archlinux up-to-date with wayland session. |
Clear the cache mentioned by @sounddrill31 . Things should work. |
But @Tudmotu said this should work without deleting cache. I'm just reporting the bug :) |
Same here on Fedora 40 after updating the system. Update: Deleted all the content from |
I figured that it happens when |
I changed the |
I have the same problem using the latest version on Fedora 40. Sometime, the issue arise and I need to clear cache for it to work again. Please reopen as this is definitely not solved. |
Reopening.
|
It seems random on my end. Sometime when I unlock my session, I get the "Text will be here" issue, most of the time everything is alright... I then delete the cache file and restart the extension and I am good for a while. |
What worked for me:
|
No, it doesn't. Also I did not have UTF8_STRING in that file, I had to remove that folder to fix extension instead. On the contrary, I did not face this issue on both Arch Linux and NixOS unstable (installed literally yesterday so i'm not sure) on another machine, which uses wayland. |
I'm using Ubuntu 23.10, Gnome 45.2, Wayland. I'm using Clipboard Indicator 57 (installed from extensions.gnome.org). Version 57 seems to be the latest version on extensions.gnome.org for Gnome 45. Should the "Text will be here" issue be fixed in version 57. If not, will version 62 work correctly in Gnome 45? |
Solution works for me. thanks! |
… on Gnome 46 (Wayland) The idea of the workaround comes from the comment: Tudmotu#459 (comment) Changing "UTF8_STRING" to "text/plain;charset=utf-8" in registry.txt seems to be fixing the problem after reloading the extension. So let's replace UTF8_STRING with text/plain;charset=utf-8 just before creating ClipboardEntry of that type, thus we should not be getting UTF8_STRING in registry.txt anymore. Without this patch "Text will be here" appears in the tray and extension is unresponsive. Fixes: Tudmotu#459 Signed-off-by: Pavel Tikhomirov <snorcht@gmail.com>
…me 46 (Wayland) The idea of the fix comes from the comment: Tudmotu#459 (comment) Changing "UTF8_STRING" to "text/plain;charset=utf-8" in registry.txt seems to be fixing the problem after reloading the extension. So let's use this.isText() instead of mimetype.startsWith('text/')) in fromJSON text checking. Without this patch "Text will be here" appears in the tray and extension is unresponsive. Fixes: Tudmotu#459 Signed-off-by: Pavel Tikhomirov <snorcht@gmail.com>
…me 46 (Wayland) The idea of the fix comes from the comment: Tudmotu#459 (comment) Changing "UTF8_STRING" to "text/plain;charset=utf-8" in registry.txt seems to be fixing the problem after reloading the extension. So let's use this.isText() instead of mimetype.startsWith('text/')) in fromJSON text checking. Without this patch "Text will be here" appears in the tray and extension is unresponsive. Fixes: Tudmotu#459 Signed-off-by: Pavel Tikhomirov <snorcht@gmail.com>
…me 46 (Wayland) The idea of the fix comes from the comment: Tudmotu#459 (comment) Changing "UTF8_STRING" to "text/plain;charset=utf-8" in registry.txt seems to be fixing the problem after reloading the extension. So let's use this.isText() instead of mimetype.startsWith('text/')) in fromJSON text checking. Without this patch "Text will be here" appears in the tray and extension is unresponsive. Fixes: Tudmotu#459 Signed-off-by: Pavel Tikhomirov <snorcht@gmail.com>
If someone still experiences the problem on latest master, please give a try to #480 and say if it helps or not. (Probably you need to fully reboot to properly reload extension.) It looks like just doing replacement in registry.txt didn't fix the problem completely, at least for me, as UTF8_STRING continues to appear there again and again (I see it appearing when I'm actively copying between Firefox and Tilix in both directions). It also looks that the problem has other manifestation: sometimes the entries with mimetype==UTF8_STRING just silently disappear instead of causing the 'stuck extension' problem mentioned in this issue. |
#480 Works fine for me, thx |
"Hier erscheint der Text" or "Text will be here" is displayed in the tray and nothing happens by clicking on it.
OS: Arch Linux x86_64
DE: Gnome 46 on Wayland
Extension version: 61
The text was updated successfully, but these errors were encountered: