DefaultIndicatorPage: should use Loader status to determine the visible property

Bug #1350555 reported by Antti Kaijanmäki
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
unity8 (Ubuntu)
Fix Released
Undecided
Antti Kaijanmäki

Bug Description

While working on ModemInfoItem for indicator-network I discovered a bug on how the items of an indicator are laid out.

This bug was very obscure, but I managed to reproduce it reliably, so I decided to try to fix it. Unfortunately I'm not completely sure what is the actual mechanism behind this bug, but I managed to figure out how to fix it anyway and I managed to reduce an simplified example which mimics the way unity8 loads the indicator items.

Related branches

Revision history for this message
Antti Kaijanmäki (kaijanmaki) wrote :

Here is the example code if somebody is interested in debugging the actual cause of this problem.

I would guess the Loader is getting confused as the Component it loads only defines implicitHeight initially.

Revision history for this message
Antti Kaijanmäki (kaijanmaki) wrote :

Here is a screenshot what happens when "visible: height > 0"
http://imgur.com/v2juYHx

The red lines indicate the top and bottom of the first item and the red lines show them for the second item. It's clear from the picture that the items overlap inside the ListView.

This is how it should look like (and this is achieved by binding the visible property to the loader status):
http://imgur.com/VQD0jLj

And here is how I first noticed the problem:
http://imgur.com/bLui6FB

As you can see the the top most items overlap with each other. Interestingly having multiple items before the "Cellular Settings..." worked just fine:
http://imgur.com/XK0fEWt

And I also noticed that triggering this misalignment seems to be racy (19 times out of 20 the items was misaligned), but after applying the attached branch the problem could not be repduced anymore.

Revision history for this message
Antti Kaijanmäki (kaijanmaki) wrote :

Oh, and just to clarify the bizarre nature of this bug it seems it only triggers when using the combination of ListView which has Loader as a delegate and the component given to it defines implicitHeight only and the component defines margins and it's implicitHeight depends on something like a label height. And this is exactly what happens when unity8 populates the indicator menus.

If the items are directly placed i.e. a Column or if the delegate is not a Loader or if the component does not define margins the bug does not manifest it self.

Michał Sawicz (saviq)
Changed in unity8:
status: New → In Progress
assignee: nobody → Antti Kaijanmäki (kaijanmaki)
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package unity8 - 8.00+14.10.20140731.1-0ubuntu1

---------------
unity8 (8.00+14.10.20140731.1-0ubuntu1) utopic; urgency=low

  [ Gerry Boland ]
  * Fix the run.sh script - pretend to be running with qtmir and emit
    SIGSTOP at the right time

  [ Ying-Chun Liu ]
  * Implement Attribute UI. (LP: #1282460)

  [ Albert Astals ]
  * Hide search history popup as soon as you start typing As discussed
    with Mike and Saviq
  * Compile with for scopes-v3 unity-api
  * PageHeader: Unfocus search field when search entry is selected
  * Show search field if the search query changes
  * Test: Add a condition for art.height being > 0 means stuff has
    already been layouted a bit without it it can happen that we get 0
    for everything at startup and tests still pass
  * Remove leftover in test of an old headerless implementation

  [ Michael Zanetti ]
  * Drop Recent apps category from Dash (LP: #1281092)
  * update launcher count emblems to match new spec (LP: #1338984)

  [ Bill Filler ]
  * disable predictive text for dash search field (LP: #1340409)

  [ CI bot ]
  * Resync trunk

  [ Antti Kaijanmäki ]
  * DefaultIndicatorPage: use Loader status to determine the visible
    property. (LP: #1350555)
 -- Ubuntu daily release <email address hidden> Thu, 31 Jul 2014 16:51:01 +0000

Changed in unity8 (Ubuntu):
status: New → Fix Released
Michał Sawicz (saviq)
Changed in unity8:
status: In Progress → Fix Released
Michał Sawicz (saviq)
Changed in unity8 (Ubuntu):
assignee: nobody → Antti Kaijanmäki (kaijanmaki)
no longer affects: unity8
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Bug attachments

Remote bug watches

Bug watches keep track of this bug in other bug trackers.