Bug 753254

Summary: gnome-shell-extensions-alternative-status-menu crashed gnome after reboot
Product: [Fedora] Fedora Reporter: gregor <gregor.binder>
Component: gnome-shell-extensionsAssignee: Rahul Sundaram <metherid>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: unspecified    
Version: 16CC: browning48ky, js, matthew.hirsch, maxamillion, metherid, michel, otaylor, pikachu.2014, samkraju, walters
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-11-30 12:37:23 EST Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Description gregor 2011-11-11 13:03:08 EST
Description of problem:
gnome-shell-extensions-alternative-status-menu crashed gnome after reboot

Version-Release number of selected component (if applicable):
fedora 16 3.1.0-7.fc16.x86_64
gnome 3.2.1
gnome-tweak-tool-3.2.0-1.fc16.noarch
gnome-shell-extension-alternative-status-menu-3.2.0-1.fc16.noarch

How reproducible:

Steps to Reproduce:
1. install gnome-shell-extensions-alternative-status-menu
2. install gnome-tweak-tool
3. start gnome-tweak-tool
4. enable the menu and check if it changes the menu
5. logout or reboot
6. login -> gnome crashed
  
Actual results:
gnome crashed

Expected results:
gnome shouldn't crash

Additional info:
Comment 1 Julian Stecklina 2011-11-21 15:09:56 EST
Still applies to: gnome-shell-extension-alternative-status-menu-3.2.0-2.fc16
Comment 2 Matt Hirsch 2011-11-30 02:40:36 EST
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?
Comment 3 Matt Hirsch 2011-11-30 03:09:33 EST
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@gnome-shell-extensions.gnome.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.
Comment 4 gregor 2011-11-30 05:59:26 EST
(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@gnome-shell-extensions.gnome.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
Comment 5 gregor 2011-11-30 06:15:01 EST
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
Comment 6 Matt Hirsch 2011-11-30 12:02:13 EST
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.
Comment 7 Owen Taylor 2011-11-30 12:22:15 EST
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.)
Comment 8 Matt Hirsch 2011-11-30 12:26:42 EST
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!
Comment 9 Mohamed El Morabity 2011-11-30 12:37:23 EST

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