GNOME Bugzilla – Bug 651503
No icon in the Application Grid
Last modified: 2016-05-25 14:00:45 UTC
Earlier the applications grid worked normally.For past few days it lists no icon/text when i click on applications tab from "Activities". I can only search and even in search some icons do not show only text is shown.
*** Bug 651504 has been marked as a duplicate of this bug. ***
Can you attach ~/.xsession-errors?
Created attachment 188898 [details] xsession-error here it is
JS ERROR: !!! Exception was: Error: Failed to convert UTF-8 string to JS string: Invalid byte sequence in conversion input JS ERROR: !!! lineNumber = '0' JS ERROR: !!! fileName = 'gjs_throw' JS ERROR: !!! stack = '("Failed to convert UTF-8 string to JS string: Invalid byte sequence in conversion input")@gjs_throw:0 You seem to have an invalid .desktop file. We should probably catch the error and log the filename of the incorrect .desktop file.
thanks for replying it so quickly. wonder why didn't i posted this earlier before. Can u tell me where are those .desktop files located may be i will correct it myself
ok i hv corrected problem on my PC. in ~/.local/share/applications there was a folder of a wine application that i had installed that had wrong encoding. I corrected that and now the problem is resolved for me. But i think shell should be able to catch this error and correct it itself.
It's impossible to "correct" it... we can only take a naive guess at the correct encoding, so either we just don't show the icon and log the error, or we display it without a name. However, wine should encode all its .desktop file data in UTF8, or at the very least ensure that all its data is valid UTF8.
Setting to NEW as the last comment indicates that this is indeed an issue that needs to be handled.
Created attachment 308501 [details] [review] appDisplay: Handle non-UTF8 filename encodings more gracefully It may be 2015, but users still stumble upon the occasional .desktop file that uses a filename encoding other than UTF-8. We currently fail quite spectacularly in that case by not displaying any apps at all - handle this case more gracefully, by only filtering out the offending apps.
Created attachment 308502 [details] [review] apps-menu: Handle non-UTF8 filename encodings more gracefully Instead of failing completely if any .desktop file uses a filename encoding other than UTF-8, just filter out the offending apps.
Review of attachment 308501 [details] [review]: There's another Gio.AppInfo.get_all() in ForderIcon._redisplay() that looks like it should have the same try/catch precaution
Review of attachment 308502 [details] [review]: ok
Created attachment 308556 [details] [review] appDisplay: Handle non-UTF8 filename encodings more gracefully Good catch, thanks!
Comment on attachment 308502 [details] [review] apps-menu: Handle non-UTF8 filename encodings more gracefully Attachment 308502 [details] pushed as d1bf592 - apps-menu: Handle non-UTF8 filename encodings more gracefully
Review of attachment 308556 [details] [review]: look fine. hopefully there aren't any other places lurking but I guess we'll hear from the bug reporters if so :-)
Attachment 308556 [details] pushed as fed79ce - appDisplay: Handle non-UTF8 filename encodings more gracefully There are probably some other issues when running an app with a bad .desktop file, for instance when trying to add it as favorite to the dash. However I don't expect it to be quite as catastrophic for other apps ...
*** Bug 664924 has been marked as a duplicate of this bug. ***