Still applies to: gnome-shell-extension-alternative-status-menu-3.2.0-2.fc16

Just to add to the report, I am also experiencing this. I checked out the latest git from here: git://git.gnome.org/gnome-shell-extensions

The latest alternative-status-menu extension still gives me this problem.

Also, I have a second computer running fedora 16 that does not get a crash when loading this extension. 

One (maybe inconsequential?) difference between the two is that the working one uses the proprietary nvidia graphics driver, and the non-working one uses the radeon driver.

Is there a way to see gnome-shell console errors after the "Problem"/"Logout" screen appears? Something similar to alt-f2, lg?

I did a bit of quick hacking around. The bug seems to be related to line 118 of 

/usr/share/gnome-shell/extensions/alternative-status-menu.org/extension.js

from gnome-shell-extension-alternative-status-menu-3.2.0-2.fc16.noarch

If I comment line 118 in enable(), 

    //statusMenu.menu.removeAll();

then gnome-shell doesn't crash. As expected, I do get a sort of double status menu with all the old menu items, plus the new menu items added by the extension.

Alternatively, I replaced 118 with:

    if('menu' in statusMenu) {
        statusMenu.menu.removeAll();
    }

This also avoids the crash, and causes the extension to work correctly when enabled after login. It seems clear that the problem is something related to the order of initialization of the extensions. Somehow, the alternative-status-menu extension is loaded before the menu is created on login. With the second fix there, the menu items added by alternative-status-menu are overwritten by the normal menu, so I have to disable and re-enable the extension to see the new menu. Someone with better understanding of gnome-shell should be able to fix this, I hope.

(In reply to comment #3)
> I did a bit of quick hacking around. The bug seems to be related to line 118 of 
> 
> /usr/share/gnome-shell/extensions/alternative-status-menu.org/extension.js
> 
> from gnome-shell-extension-alternative-status-menu-3.2.0-2.fc16.noarch
> 
> If I comment line 118 in enable(), 
> 
>     //statusMenu.menu.removeAll();
> 
> then gnome-shell doesn't crash. As expected, I do get a sort of double status
> menu with all the old menu items, plus the new menu items added by the
> extension.
> 
> Alternatively, I replaced 118 with:
> 
>     if('menu' in statusMenu) {
>         statusMenu.menu.removeAll();
>     }
> 
> This also avoids the crash, and causes the extension to work correctly when
> enabled after login. It seems clear that the problem is something related to
> the order of initialization of the extensions. Somehow, the
> alternative-status-menu extension is loaded before the menu is created on
> login. With the second fix there, the menu items added by
> alternative-status-menu are overwritten by the normal menu, so I have to
> disable and re-enable the extension to see the new menu. Someone with better
> understanding of gnome-shell should be able to fix this, I hope.

hi, 

replaced this line an it works.

THANK YOU

update:
on my workstations it worked but on my laptop it crashed, there i have also the bluetooth menu icon. don't know if this is the problem

gregor, it shouldn't really work as intended, just not crash.

It seems the whole extension loading system in gnome3 is kind of a mess. These guys did some tests and found that there is no mechanism to control the order of extension loading:

http://www.consumerreports.org/cro/consumer-reports-magazine-january-2012/arsenic-in-your-juice.html

They appear to load in the order that you install them. (Perhaps in the order that they appear on the disk, e.g. ls -f).

I guess js/ui/userMenu.js is responsible for adding the menu concerned when gnome3 starts. I still don't know how to get a better measurement of when these different scripts are called, but my guess is still that somehow the alternate-status-menu extension is loaded before js/ui/userMenu.js in some circumstances.

I presume that other shell extensions could be subject to similar pitfalls. Pure speculation here, but it could be that the devs don't see this because it depends on some subtle order of file creation, and they typically don't install via rpm, which could create files in a different order than a make install.

Moving to the right component; if an extension crashes gnome-shell, it's the extensions problem.

Wow, Consumer Reports was testing GNOME Shell?

(There have been some changes to how extension ordering work in the 3.4 development process.)

Haha.. Fair enough. This is what I meant to post: http://forums.linuxmint.com/viewtopic.php?f=205&t=85775&start=120

So... you do read these!

*** This bug has been marked as a duplicate of bug 739271 ***