Extension breaks when accessing Overview or applications list (Focal)

I'm posting a screencast of the issue, as it may be more clear what the issue is.

At 0:22 I click Show Applications, around 0:38 I use keyboard shortcuts to move back and forth between the first and second virtual desktop.

Checking the logs I found the following, possibly related, which appeared during the screencast:

sender: gnome-shell, time: 23:15:49
../clutter/clutter/clutter-actor.c:10556: The clutter_actor_set_allocation() function can only be called from within the implementation of the ClutterActor::allocate() virtual function.

sender: gnome-shell, time: 23:16:15
JS ERROR: TypeError: this._updateWorkspacesFullGeometry is not a function
_newUpdateWorkspacesViews@/<email address hidden>/panelManager.js:464:14
show@resource:///org/gnome/shell/ui/workspacesView.js:613:14

sender: gnome-shell, time: 23:16:15
JS ERROR: TypeError: area is null
padArea@resource:///org/gnome/shell/ui/workspace.js:1101:9
_updateWindowPositions@resource:///org/gnome/shell/ui/workspace.js:1334:20
_realRecalculateWindowPositions@resource:///org/gnome/shell/ui/workspace.js:1311:14
_recalculateWindowPositions/this._positionWindowsId<@resource:///org/gnome/shell/ui/workspace.js:1286:18

sender: gnome-shell, time: 23:16:23
JS WARNING: [resource:///org/gnome/shell/ui/workspaceThumbnail.js 813]: reference to undefined property 0

sender: gnome-shell, time: >50x from 23:16:23 to 23:16:27
JS ERROR: TypeError: this._thumbnails[0] is undefined
handleDragOver@resource:///org/gnome/shell/ui/workspaceThumbnail.js:813:13
_updateDragHover@resource:///org/gnome/shell/ui/dnd.js:514:47

sender: gnome-shell, time: 23:17:17
Window manager warning: META_CURRENT_TIME used to choose focus window; focus window may not be correct.

sender: gsd-media-keys, time: 23:17:17
Failed to grab accelerators: GDBus.Error:org.freedesktop.DBus.Error.UnknownMethod: No such interface “org.gnome.Shell” on object at path /org/gnome/Shell

sender: gsd-media-keys, time: 23:17:18
Failed to grab accelerators: GDBus.Error:org.freedesktop.DBus.Error.UnknownMethod: No such interface “org.gnome.Shell” on object at path /org/gnome/Shell

sender: gnome-shell, time: 23:17:18
JS WARNING: [/<email address hidden>/appIcons.js 694]: reference to undefined property "_tweeningToSize"

Upstream issue: https://github.com/home-sweet-gnome/dash-to-panel/issues/1139

The commit to cherry pick to fix this issue is likely this one: https://github.com/home-sweet-gnome/dash-to-panel/commit/ed00ae61ba5c81ceec6e5bb9f04afa8272fac13a

Status changed to 'Confirmed' because the bug affects multiple users.

I tried the groovy package, works fine on focal with several machines. Maybe backporting it to focal would be the best the easiest way to fix this?

I installed version 38-2 from Groovy and I confirm that it works correctly on focal and fixes the issue.

Link to Version 38-2 from Groovy: https://launchpad.net/ubuntu/groovy/amd64/gnome-shell-extension-dash-to-panel/38-2

If someone tells me how to upload the package to launchpad, I can try cherry picking the fix and upload for review

Debdiff from 31-1 to 38-2 for fixing this bug. This needs SRU. Can someone please upload it?

This signed patch backports the groovy package to focal, which fixes this bug. However in debian/control I kept Build-Depends: debhelper-compat (= 12) as a higher version is not available in focal.

Hello,

I've been pointed this this sponsorship request. Might I ask you to provide me a diff on top of groovy? the diff from focal is good to see what changes are done, but applying that is quite a pain :)

Also, please use version "31-2~ubuntu20.04.1" so that it can sort correctly

Sorry, make that "38-2~ubuntu20.04.1"

Hi, and thanks for taking care of this.

I this the kind of diff you wanted?

Added mention in changelog of the debian/control required version changed from 13 to 12

Patch as suggested by gunnarhj, mentioning SRU, debhelper-compat changed to version 12 (from 13) for compatibility with focal and change of maintainer on Ubuntu

Uploaded!

Thank you very much, Mattia. Should I do something else about it until the SRU team eventually asks something?

On 2020-09-07 15:06, fcole90 wrote:
> Should I do something else about it until the SRU team eventually
> asks something?

Nope, nothing to do until an SRU team member has reviewed and (hopefully) uploaded it to focal-proposed. You'll see here when that happens.

Perfect, thank you very much for your precious mentoring!

If there is a one-liner that fixes this in Focal, why are you proposing a backport from Groovy instead? The trivial backport is what SRU policy requires in the first instance as that is assumed to carry a much lower regression risk. Backporting other changes needs separate justification please, and is generally going to be harder to review and get landed.

I was of your same opinion in the beginning, but then I realised that while that one-liner should be the fix, it has not been designed nor tested to be used on top of version 31 (the version currently available in focal) but on top of version 38. If you check the debian/changelog you can notice that in fact the fix is what bumped the package version from 38-1 to 38-2.

Hence to me it seems a greater risk to cherry-pick that fix alone on version 31, and then be on our own, rather than using version 38 with the fix, which is where it was intended and released upstream.

As for the potential of regression, there is none in my opinion, as the current version of the package breaks the interaction so badly that it becomes completely unusable, so this change can only be an improvement on that side.

Thank you for the reply. Looks like you're making two separate arguments for why a version bump from 31 to 38 is appropriate here, instead of a cherry-pick of the fix:

1) "while that one-liner should be the fix, it has not been designed nor tested to be used on top of version 31"

2) "As for the potential of regression, there is none in my opinion"

Let me take these one at a time.

> while that one-liner should be the fix, it has not been designed nor tested to be used on top of version 31

This argument also applies generally to Ubuntu SRU policy, which is specifically to favour cherry-picks over taking more unrelated changes from a newer upstream release. The majority of stable release updates in Ubuntu cherry-pick from upstream exactly like this, and these fixes are rarely designed nor tested by upstream on the base on which Ubuntu applies them. Our cherry-picking favouring policy is documented at https://wiki.ubuntu.com/StableReleaseUpdates. Ubuntu as a project has made a policy choice here, and you've given no other reason for an exception in this case except that you disagree with Ubuntu's policy. You're entitled to your opinion of course, and you're welcome to petition for Ubuntu to change its policy. However in the absence of an explanation why the policy is as an exception inappropriate to this case, I think it's appropriate to follow the policy until (and if) it is changed. Otherwise there would be no point in having a policy.

> As for the potential of regression, there is none in my opinion, as the current version of the package breaks the interaction so badly that it becomes completely unusable, so this change can only be an improvement on that side.

Nobody proposes a change that is known to carry a regression, of course. The challenge with assessing regression risk is to think about what we don't know. Here are two cases where regression risk lies that I don't think you've considered:

1) Users who take updates from focal-security but not focal-updates. My understanding is that these users are not currently regressed as they are still using the release versions of gnome-shell and gnome-shell-extension-dash-to-panel. If we accept your version bump and there's subsequently a security update required to gnome-shell-extension-dash-to-panel, then these users would be exposed to any regressions that might exist in moving from a working 31 to 38. So the idea that there is no possible regression because it's already too broken doesn't apply in this case - because it's not already too broken for these users.

2) Changes in one package can affect others, especially if there are bugs. It's not safe to assume that changing this package cannot possibly regress other behaviour without investigating more deeply.

My conclusion remains that it is appropriate to cherry-pick the fix in line with Ubuntu SRU policy, and I haven't seen any reason to deviate from this policy in this particular case.

You (or anybody else who wants to volunteer) now has three choices:

1) Prepare an minimal upload that fixes this bug, as appears to be easily technically possible.

2) Present reasons why the usual policy to cherry-pick is not appropriate in this pa...

TLDR:
I'll prepare a package with the patch alone :)

---

Thank you very much for taking care of writing me such a long and detailed explanation, I really appreciated it. In particular you not only explained me the general rule but also how in particular to this package, like for the potential for regressions. I definitely see now much more risks involved than I had previously considered.
Thank you for making me change my mind in such an instructive way :)

Hi, this is the fix by cherry-picking only the needed lines.

uploaded! (after removing the useless %23 from Bug-Debian and dropping the newline-at-end-of-file change)

Thanks you very much :)

I'm experiencing the issue again with the patched package. I'm going to check why and send a new fix

It seems it was a false alarm. I purged and reinstalled the extension and seems to be working correctly (using the patched version). So, I think the review can continue :)

[Regression Potential]

Code relating to updating the visual appearance of things is being altered. If there is a regression, it is likely to manifest in high level UI behaviour.

There is a different code path for before and after the breaking gnome-shell change, so behaviour may be different depending on whether the release pocket or the updates pocket version of gnome-shell is used.

Please test both cases during SRU verification.

Hello fcole90, or anyone else affected,

Accepted gnome-shell-extension-dash-to-panel into focal-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/gnome-shell-extension-dash-to-panel/31-1ubuntu20.04.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-focal to verification-done-focal. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-focal. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

I just tested the built package using the updates pocket version of gnome-shell.

I installed again the current package (31-1), reproduced the bug, installed the fixed version (31-1ubuntu20.04.1), tested again, and the bug is fixed.

I'll later test it again on the release pocket on a VM

I run a VM where I just installed ubuntu 20.04.1, but it has already gnome-shell 3.36.4-1ubuntu1~20.04.2, so I'm not sure how to test for the release pocket

Try to downgrade:

sudo apt install gnome-shell=3.36.1-5ubuntu1 gnome-shell-common=3.36.1-5ubuntu1 gnome-shell-extension-prefs=3.36.1-5ubuntu1

I can confirm that https://launchpad.net/ubuntu/+source/gnome-shell-extension-dash-to-panel/31-1ubuntu20.04.1/+build/19943968 fixes the problem for me on gnome-shell 3.36.4-1ubuntu~20.04.2:

The overview shows the application widgets correctly again. Selecting a widget closes the overview and brings the application to the front.

Thank you all!

I confirm it works also on 3.36.1-5ubuntu1 with no issues.

--------------------------------------------------------------

Thanks Gunnar for your suggestion and thanks Jo for testing.

I could finally find the 20.04 iso here: http://old-releases.ubuntu.com/releases/20.04/ (Despite the page title it doesn't containe only betas). I changed the settings to only security updates but it still tries to update to the latest gnome-shell, IDK why. So I just installed version 31-1 of the package, it worked correctly (it was not an issue with previous versions of gnome-shell), then also the fixed version 31-1ubuntu20.04.1 and it worked as well. I double checked and the version of gnome-shell was still 3.36.1-5ubuntu1, so from the release pocket.

Hi Fabio,
I ran into the same issue today (bug 1896188 now marked a dup of this one) and I'm very happy to see your fix already in focal-proposed - thanks!.

I can (as the other reporters) confirm that the version in focal-proposed works fine.

This bug was fixed in the package gnome-shell-extension-dash-to-panel - 31-1ubuntu20.04.1

---------------
gnome-shell-extension-dash-to-panel (31-1ubuntu20.04.1) focal; urgency=medium

  * Apply patch as SRU to fix extension breaking, bug (LP: #1892245)

 -- Fabio Colella <email address hidden> Thu, 10 Sep 2020 11:37:11 +0200

The verification of the Stable Release Update for gnome-shell-extension-dash-to-panel has completed successfully and the package is now being released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.