Manage Scopes -> All Is Unusable

i see the same issue.

also on mako

You guys have some special phones, I totally can't reproduce this :/

Tried on both krillin (rtm-proposed an devel-proposed) and mako (rtm-proposed), everything behaves fine... And this wouldn't have gotten through ours *and* QA's testing if it was common.

Is this constant for you? Are there any steps you're taking that lead to this? :|

I updated to #99 rtm-proposed,rebooted and cannot reproduce. I'll play with it a bit more, spec. re adding / removing scopes and will report if I can reproduce

I have done a lot of favoriting and unfavoritng of scopes. That's the only thing that I can think of that would be at all relevant.

Rick - could you check if you can see this bug?
https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1380133

I did :
 ubuntu-device-flash --channel=ubuntu-touch/ubuntu-rtm/14.09-proposed --revision=100 , this clear up both problems for me.

then I did:
 ubuntu-device-flash --channel=ubuntu-touch/ubuntu-rtm/14.09-proposed --revision=96
and OTA'd to r100, and both problems are back

try this to reproduce please

Probable duplicate: bug #1380133.

Correction. This is a QML compilation issue. Removing ~/.cache/QML/unity8-dash makes this go away for me.

Make that ~/.cache/QML/Apps/unity8-dash

a session upstart job that flushes the cache after upgrades should be shipped (with lxc-android-config or ubuntu-touch-session)
i.e call it /usr/share/upstart/sessions/clear-qml-caches.conf with the following content (untested, but should work):

# This allows to flush all app caches when
# a new image version arrives

start on :sys:boot-hooks WHEN=new-version

pre-start script
    # clear all QML app caches on image upgrade
    CACHEDIR="$HOME/.cache/QML"
    [ -e $CACHEDIR ] && rm -rf $CACHEDIR/*
end script

I upgrade to r101 and after reboot could still reproduce the image. In order to test ogra's solution:
I ran phablet@ubuntu-phablet:~$ rm -R .cache/QML/*
 and rebooted. After the reboot, I could no longer reproduce the issue.

Silo 17 will soon have some fresh code to test, it should prevent this issue.

I still see the issue; will not clean the cache in case you need someone to validate that it auto recovers after landing the fix. Let me know (ping on IRC) if I shall test something.

I can confirm that silo 17 fixes the issue without having to do anything else with caches etc...

Will keep using this silo for a while in case there are other regressions, but so far it looks good...