fix: disconnect signals before destroying objects in disable()
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 78/100
- Issue type
- Bug
- Clarity
- Clearly specified
- Activity status
- Quiet
- Tech stack
- typescript
- Domain
- desktop
Research direction
Start at disable() around extension.js:573 and inspect the signal cleanup in utils/signalHandling.js. Verify that signal disconnection occurs before the Indicator and keybindings objects are destroyed, then reproduce or check the reported GObject assertion during disable().
Written by the indexing model from the issue text.
Description
Bug
When the extension is disabled (e.g. during automatic suspend), `disable()`
destroys `_indicator` and `_keybindings` before calling `_signals.disconnect()`.
Both objects have signal handlers registered via `_signals`, so disconnecting
after destroying them causes a GObject assertion failure:
```
Object Indicator (0x55993d6d0950), has been already disposed — impossible
to access it.
== Stack trace for context 0x55993bd19f70 ==
#0 resource:///org/gnome/gjs/modules/core/overrides/GObject.js:710
#1 tilingshell@ferrarodomenico.com/utils/signalHandling.js:17
#2 self-hosted:157
#3 tilingshell@ferrarodomenico.com/utils/signalHandling.js:16
#4 tilingshell@ferrarodomenico.com/extension.js:573
#5 resource:///org/gnome/shell/ui/extensionSystem.js:217
```
This leaves GNOME Shell in a partially torn-down state, which can cascade into
dash-to-dock and other extensions having corrupted actor trees, ultimately
deadlocking the Wayland compositor when gsd-power attempts to coordinate a
suspend.
Fix
Move `_signals?.disconnect()` / `_signals = null` to the top of `disable()`,
before any `destroy()` calls. I have a fix ready as a PR.
Environment
- Fedora, GNOME 49.6
- tilingshell 17.3
- Dominant language
- TypeScript
- Stars
- 2k
- Forks
- 117
- PR merge metrics
- No merged PRs in 30d
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from domferr/tilingshell
-
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
domferr/tilingshell#602 ·
-
bug next release
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
domferr/tilingshell#541 · 1 comment · 4 reactions ·
-
Difficulty 4/5 3-5 days Newbie friendliness 48/100
domferr/tilingshell#609 ·
-
Difficulty 4/5 3-5 days Newbie friendliness 38/100
domferr/tilingshell#608 ·
-
Difficulty 4/5 3-5 days Newbie friendliness 48/100
domferr/tilingshell#607 ·
All issues in domferr/tilingshell
Similar issues
-
calcite-components needs triage refactor
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
Esri/calcite-design-system#15203 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 91/100
-
community first-timers-only good first issue hacktoberfest help wanted low hanging fruit up-for-grabs
Difficulty 1/5 Under an hour Newbie friendliness 95/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Automattic/studio#4908 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 90/100