Empty tab header obscures the queue's close button

[David Planella]

I've yet not found a reliable way to trigger it, but while testing r173 I've had this happening a few times on the desktop. Last time I could reproduce it, I was:

- Playing a song in the queue
- Pressed the Back button
- An empty tab header appears on top, blocking the navigation to close the queue (see attached screenshot)

This then requires a restart of the app to be able to navigate out of the queue view.

I'm not sure if these messages are relevant, but here's an extract of the latest output from the command line when I last saw the issue:

mainView.isPlaying=false, QtPowerd.keepAlive=false
Debug: MusicQueue update currentIndex: file:///home/dpm/Music/The Dresden Dolls/The Dresden Dolls/05. 672.mp3
MediaPlayer statusChanged, currentIndex: 16
Playing: file:///home/dpm/Music/The Dresden Dolls/The Dresden Dolls/05. 672.mp3
requestSysState: QDBusError("org.freedesktop.DBus.Error.ServiceUnknown", "The name com.canonical.powerd was not provided by any .service files")
mainView.isPlaying=true, QtPowerd.keepAlive=false
Debug: no scrobbling
mainView.isPlaying=false, QtPowerd.keepAlive=false
QXcbWindow: Unhandled client message: "_GTK_LOAD_ICONTHEMES"
Violació de segment (bolcat de la imatge del nucli)

[Victor Thompson (vthompson)]

We tried to mitigate this bug by allowing the user to go back via the HUD. This of course doesn't help when running on the desktop.

I've tried to get this bug to happen on a device and have been unsuccessful thus far. Which is good.

[David Planella (dpm)]

Decreasing importance as I could not reproduce it on the device yet.

[Andrew Hayzen (ahayzen)]

This is really random, but very annoying when it occurs.

The most reproduceable steps I have seem to be.
- Go to the songs tab
- Scroll up/down the list for a bit
- Open the now playing page
- Scroll up/down and switch tracks
- It will sometimes occur, usually when scrolling up

[Andrew Hayzen (ahayzen)]

I think this is repoducible.

- Switch to the album tab
- Click on a album that will have enough tracks to fill the now playing page
- Click on a song in the album to start playing
- Notice the white band at the top

[Andrew Hayzen (ahayzen)]

If I comment out the lines
header.visible = false;
header.opacity = 0;

In the musicNowPlaying you don't get a white strip but you can see that header.hide() has failed as the header is still there.
If you then uncomment header.opacity = 0; the header correctly disappears but mouseFocus is still given to it rather than the back button.

It is header.visible = false; that is actually causing the white strip but this is due to header.hide() failing.

[Ubuntu Phone Apps Jenkins Bot (ubuntu-phone-apps-jenkins-bot)]

Fix committed into lp:music-app at revision None, scheduled for release in music-app, milestone 1.0

[Victor Thompson (vthompson)]

This seems to still occur ocassionally. I saw it earlier on my device.

[Fabian Herb (fherb)]

I don't think this is random: just tap on a song from the "Songs" tab. I have a 100% chance to get the empty header. Selecting songs from "Albums" or "Artists" works fine.

Still present on version 1.1.235.

[Andrew Hayzen (ahayzen)]

Hi Fabian,

Would you be able to take a video/screenshots at each stage and provide information about the device you are running it on phone/desktop/image version? As I have not, as of yet, been able to reproduce this - but I may not be following your steps correctly.

Thanks

[Fabian Herb (fherb)]

Hi,

I have only started using the phone again on a daily basis a few days ago, previously unsuccessfully waiting for a trusty image that's usable, so I'm back on image 100 now.

I'm afraid I'm not able to reproduce it on purpose any more with a recent version of the app. But I still saw it happen once today.

I use the music app a lot, so I'll let you know when I find out more.

Btw., I really hope that this close button is not final, because it ignores any existing UI design pattern for Ubuntu Touch. I think it took me at least a week to find it, but that may be partially the case because it was obscured most of the time ;).

[Andrew Hayzen (ahayzen)]

This appears for me on the latest build [1], using the latest branch [2] when clicking on a song from the artist/songs tab on device [Nexus 4].

If on the desktop I can repoduce by going to the artist tab and selecting an artist with only 1 song.

1 - current build number: 68
device name: mako
channel: trusty
last update: 2013-12-17 13:37:34
version version: 68
version ubuntu: 20131216
version device: 20131211.2
2 - lp:music-app as of #278

[Andrew Hayzen (ahayzen)]

Also seems to occur only if you have clicked on a track from the artist/songs tab and the track queue is empty.

Furthermore it is still occuring on the latest image
current build number: 70
device name: mako
channel: trusty
last update: 2013-12-17 20:38:33
version version: 70
version ubuntu: 20131217
version device: 20131211.2

[Victor Thompson (vthompson)]

This bug happens anytime the Now Playing page is flicked up or down when the phone is updated to Qt 5.2 per the following instructions:

Upgrade instructions on the device:
adb shell
apt-add-repository ppa:ci-train-ppa-service/landing-006
apt-get update
apt-get dist-upgrade
# in case of lxc-android-config or other failures:
# dpkg --configure -a
reboot

Qt 5.2 is to be deployed soon.

[Victor Thompson (vthompson)]

Moving the importance back to 'Medium'. My previous comment #14, seems to only be true if the ~/Music directory is filled with the 3 test songs after running 'phablet-test-run -v music_app'. I'm not sure what's causing this to occur when just those 3 songs are in the library.

[Victor Thompson (vthompson)]

I've also caused the behavior seen in comment #14 when I go to the queue from the Playlist tab with only a few playlists in the ListView. As soon as there are enough playlists to cause the header to hide when you flick through the list the behavior goes away.

[Ubuntu Phone Apps Jenkins Bot (ubuntu-phone-apps-jenkins-bot)]

Fix committed into lp:music-app at revision None, scheduled for release in music-app, milestone 1.0