Fix context menu null errors after wake from sleep

[riogesta]

Occasionally after waking the device from sleep or unlocking the screen, GNOME Shell would throw:
TypeError: can't access property "isOpen", this._contextMenu is null

This was caused by a lifecycle / initialization order issue during wake/enable where _panelController.enable() ran before _panelInteractionController.enable(). Early window focus and dodge signals queried interactionIsBlocked and menuIsOpen before this._contextMenu had been instantiated, leading to the crash.

What this PR does:

• Reorders controller initialization in extension.js so interaction and start button controllers are ready before the panel controller starts handling window events.

[Sultech]

Thanks for the report. The initialization order change looks plausible, but could you share the full journalctl stack trace for the this._contextMenu is null error, including the file and line number? That would help confirm which controller is involved and whether the reordered calls fix it.

The other null guards appear broader than the reported error and may hide an initialization problem. In particular, prefs.js passes the rows and buttons guarded in panelModeGroup.js. Please also share the full stack trace for the preferences error and, if possible, the extension commit or version that was installed when it happened. Once we have those traces, we can narrow the PR to the guards that are actually needed.

[riogesta]

Here is the full journalctl stack trace for the this._contextMenu is null error on GNOME Shell 50:

  JS ERROR: TypeError: can't access property "isOpen", this._contextMenu is null
  get menuIsOpen@file:///home/rgsvt/.local/share/gnome-shell/extensions/simple-
  taskbar@sultech/src/panel/panelInteractionController.js:76:9
  _panelInteractionIsBlocked@file:///home/rgsvt/.local/share/gnome-shell/extensions/simple-
  taskbar@sultech/extension.js:584:13
  _panelAutoHideIsBlocked@file:///home/rgsvt/.local/share/gnome-shell/extensions/simple-
  taskbar@sultech/extension.js:575:21
  isAutoHideBlocked@file:///home/rgsvt/.local/share/gnome-shell/extensions/simple-
  taskbar@sultech/extension.js:238:43
  isBlocked@file:///home/rgsvt/.local/share/gnome-shell/extensions/simple-
  taskbar@sultech/src/panel/panelController.js:121:35
  _isBlocked@file:///home/rgsvt/.local/share/gnome-shell/extensions/simple-
  taskbar@sultech/src/panel/panelAutoHideController.js:613:18
  _scheduleHide/this._hideTimeoutId<@file:///home/rgsvt/.local/share/gnome-
  shell/extensions/simple-taskbar@sultech/src/panel/panelAutoHideController.js:551:26
  @resource:///org/gnome/shell/ui/init.js:20:20

The error originates in panelInteractionController.js. On wake/enable, _panelController.enable() triggers _scheduleHide, which checks isAutoHideBlocked and queries menuIsOpen before _panelInteractionController.enable() has initialized this._contextMenu.

Regarding the preferences error, that was caused by a version mismatch during local testing. I was testing on an existing v63 install and had only copied src/ without updating prefs.js from main, so taskbarModeRow was missing. With prefs.js from main, that error does not occur.

I can remove the preferences guards and keep the PR focused only on the initialization order and panelInteractionController. Let me know if that works for you.

[Sultech]

Thanks for the stack trace and for explaining the preferences error. Please remove the preferences guards and the other optional chaining changes.

The trace confirms that panelInteractionController.menuIsOpen was called while _contextMenu was null. Could you test the initialization-order change using a fresh package built from current main, with all files from the same commit? If the error still occurs, please send the journal lines immediately before the stack trace as well. That will help us tell whether enable was interrupted or the timeout ran during initialization. We can then review the smallest fix needed.

Install from source:

git clone https://github.com/Sultech/simple-taskbar.git
cd simple-taskbar
./package.sh
gnome-extensions install --force dist/simple-taskbar@sultech.shell-extension.zip

Then logout and back in

[riogesta]

The branch has been updated to keep only the initialization order change in extension.js, removing the preferences guards and optional chaining.

I built and installed the extension from source via ./package.sh, then verified by locking and unlocking the screen with a fullscreen window. The taskbar initialized as expected without any this._contextMenu is null errors in journalctl.

[Sultech]

Thanks, the updated change looks good. The initialization order fixes the confirmed lifecycle issue without adding unnecessary null guards. Please update the PR description to remove references to the optional chaining and preferences guards, since those changes are no longer included. After that, I’m happy to merge it.

[riogesta]

Updated the PR description. Thanks!