GNOME Bugzilla – Bug 790766
Dash stops showing non-pinned (non-"Favourite") running applications
Last modified: 2017-11-23 22:38:33 UTC
On one of my user accounts on 3.26, the Dash sometimes gets into a state where it only shows pinned ("Favourite"/"Favorite") items, and not other running applications. The pinned items show correctly however (i.e. the "running" highlight correctly reflects the application's running state). The main applications icon grid correctly highlights the running state of the non-pinned applications, and the running windows are all shown in the overview. Only re-logging in fixes the issue. I ordinarily use Dash to Panel, and I've found that when I see a bug where Dash to Panel loses all of its items from its panel bar, if I then disable the extension, Shell's Dash is in this state (missing non-pinned items); re-enabling Dash to Panel it still lacks all its items - so it seems the two things are related. I don't know if it's possible for an extension to cause session-persistent corruption of Shell's default components (i.e. Dash in this case) even after the extension has been disabled? There's a related bug for Dash to Panel here (it's older, but this bug in Shell (and the persistence of the bug in DtP after reloading the extension) is new for 3.26): https://github.com/jderose9/dash-to-panel/issues/92
(In reply to Stephen from comment #0) > I don't know if it's possible for an extension to cause > session-persistent corruption of Shell's default components (i.e. Dash in > this case) even after the extension has been disabled? Yes. Extensions get access to all internals, and there's no way to track what changes an extension does - disabling really boils down to asking the extension to please revert any changes it made. Regarding the issue itself: I've never heard of this before, so can you reproduce the problem without the extension? Given that dash-to-dock *replaces* the built-in dash when enabled, it's certainly possible that this is an extension bug. Maybe there are some related errors in journalctl that could provide a clue?
I haven't tried reproducing without the extension, if I can convince myself to cope without it for a while I will ;) Fair enough re. Shell not managing extension state; I'll assume it's the extension's fault and close for now (..mumble mumble proper extension API something something... ;))
(In reply to Stephen from comment #2) > (..mumble mumble proper extension API something something... ;)) If this is indeed an issue in the dash-to-dock extension, then a proper extension API would certainly have prevented it - because a proper API wouldn't allow extensions to rip out core components, so the extension wouldn't exist in the first place ...
No, it would allow cleanly disabling shell components so extensions wouldn't *have* to rip out core components ;)