GNOME Bugzilla – Bug 687653
Fail to start gnome-shell master (Error: can't convert this._frame to an integer)
Last modified: 2012-11-05 19:33:18 UTC
I just updated to Shell master (e04a4c39231ea1418591446d9b98aad4d7bcd2de) and now get this exception when trying to start it: JS ERROR: !!! Exception was: Error: can't convert this._frame to an integer JS ERROR: !!! message = '"can't convert this._frame to an integer"' JS ERROR: !!! fileName = '"/home/cassidy/usr/share/gnome-shell/js/ui/panel.js"' JS ERROR: !!! lineNumber = '113' JS ERROR: !!! stack = '"(1)@/home/cassidy/usr/share/gnome-shell/js/ui/panel.js:113 wrapper(1)@/home/cassidy/usr/share/gjs-1.0/lang.js:204 ()@/home/cassidy/usr/share/gnome-shell/js/ui/panel.js:119 wrapper()@/home/cassidy/usr/share/gjs-1.0/lang.js:204 ("process-working.svg",24)@/home/cassidy/usr/share/gnome-shell/js/ui/panel.js:91 wrapper("process-working.svg",24)@/home/cassidy/usr/share/gjs-1.0/lang.js:204 ("process-working.svg",24)@/home/cassidy/usr/share/gjs-1.0/lang.js:145 ("process-working.svg",24)@/home/cassidy/usr/share/gjs-1.0/lang.js:239 ([object Object])@/home/cassidy/usr/share/gnome-shell/js/ui/panel.js:277 wrapper([object Object])@/home/cassidy/usr/share/gjs-1.0/lang.js:204 ([object Object])@/home/cassidy/usr/share/gjs-1.0/lang.js:145 ([object Object])@/home/cassidy/usr/share/gjs-1.0/lang.js:239 ("appMenu")@/home/cassidy/usr/share/gnome-shell/js/ui/panel.js:1170 wrapper("appMenu")@/home/cassidy/usr/share/gjs-1.0/lang.js:204 ([object Array],[object _private_St_BoxLayout])@/home/cassidy/usr/share/gnome-shell/js/ui/panel.js:1181 wrapper([object Array],[object _private_St_BoxLayout])@/home/cassidy/usr/share/gjs-1.0/lang.js:204 ()@/home/cassidy/usr/share/gnome-shell/js/ui/panel.js:1134 wrapper()@/home/cassidy/usr/share/gjs-1.0/lang.js:204 ()@/home/cassidy/usr/share/gnome-shell/js/ui/panel.js:984 wrapper()@/home/cassidy/usr/share/gjs-1.0/lang.js:204 ()@/home/cassidy/usr/share/gjs-1.0/lang.js:145 ()@/home/cassidy/usr/share/gjs-1.0/lang.js:239 start()@/home/cassidy/usr/share/gnome-shell/js/ui/main.js:144 @<main>:1 "' Avertissement du gestionnaire de fenêtres : Log level 32: Execution of main.js threw exception: Error: can't convert this._frame to an integer
Looks like this._frame is NaN because this._animations.get_n_children() returned 0 (frame == 1)
Adding an early return if get_n_children() returns 0 seems to work but I have no idea if that's the proper fix or not.
Created attachment 228133 [details] [review] panel: Fix a regression from the previous commit The TextureCache is loaded asynchronously, so at the first update we do not have the number of images yet and this._frame gets NaN. We simply do not update in the constructor, like it used to be before. (Move the bug here from 687583)
How about modifying start() to call show() on the actor at index this._frame? Wouldn't that fix the original issue you were seeing? (IIUC it's that the first time the actor is shown, all of the children are hidden).
(In reply to comment #4) > How about modifying start() to call show() on the actor at index this._frame? > Wouldn't that fix the original issue you were seeing? (IIUC it's that the first > time the actor is shown, all of the children are hidden). Because this does not change the problem? If you create an AnimatedIcon and call start() right after, there is still no children... We will get them once images are loaded, it's still racy.
(In reply to comment #5) > (In reply to comment #4) > > How about modifying start() to call show() on the actor at index this._frame? > > Wouldn't that fix the original issue you were seeing? (IIUC it's that the first > > time the actor is shown, all of the children are hidden). > > Because this does not change the problem? If you create an AnimatedIcon and > call start() right after, there is still no children... We will get them once > images are loaded, it's still racy. I think I was clear that it would fix the *original* problem you were seeing. Of course, it doesn't fix the race.
The best thing to do would be to add a GAsyncReadyCallback to load_sliced_images, and keep track of two states: isLoaded, and isPlaying. I'm sure you can figure out how the two interact. ( I didn't mention this in the initial review simply because I forgot, but I wanted to rename start/stop to play/stop )
I thought it would be a bit overkill to go that road, but that's the robust way to do it. I'm trying to implement it, but in the mean time, master is broken, we should revert or commit the given fix (or just do nothing in _showFrame if we have no image)?
I'd appreciate it if we could get things running sooner rather than later. There are new commits that I need to test.
Let's revert the fix for now.
Reverted. *** This bug has been marked as a duplicate of bug 687112 ***