can't display toolbar after dismissing it

Bug #1332632 reported by Bill Filler
24
This bug affects 3 people
Affects Status Importance Assigned to Milestone
Mir
Fix Released
Critical
Alexandros Frantzis
gallery-app
Fix Released
Critical
Arthur Mello
gallery-app (Ubuntu)
Fix Released
Undecided
Unassigned
mir (Ubuntu)
Fix Released
Critical
Unassigned

Bug Description

with image 91

- open a photo in the gallery, and toolbar will be visble
- swipe away toolbar or navigate to another photo

toolbar will now not be able to be opened anymore by swiping up

Related branches

Revision history for this message
Bill Filler (bfiller) wrote :

Seems to have broken between image 88 and image 89. Here is what changed in image 89:
http://people.canonical.com/~ogra/touch-image-stats/89.changes

Changed in gallery-app:
importance: Undecided → Critical
assignee: nobody → Arthur Mello (artmello)
Bill Filler (bfiller)
summary: - can display toolbar after dismissing it
+ can't display toolbar after dismissing it
Arthur Mello (artmello)
Changed in gallery-app:
status: New → In Progress
Revision history for this message
Arthur Mello (artmello) wrote :

The problem seems to be that the window height is wrong for gallery on phone devices. The application window height is set for a size bigger than the screen height. With this we are not able to access the bottom swipe area of the window to reopen the toolbar. This problem happens only after we call setWindowState(Qt::WindowFullScreen); . We set window state for fullscreen always when we are not on desktop for gallery. For some reason the height is wrong on fullscreen mode on devices. But it does not seem to be a Qt 5.3 issue since we got the problem between images 88 and 89.

To fix that I am removing the default call for fullscreen mode on devices. That seems as an unnecessary call and removing it fix the problem, at least on my tests.

Revision history for this message
Jean-Baptiste Lallement (jibel) wrote :

Please also fix the testsuite to reliably report failures when the toolbar is broken (bug 1333607)

Revision history for this message
Bill Filler (bfiller) wrote :

Can the Mir team also pls look into this? Seems problem occurring since new version of Mir uploaded in image 89

Revision history for this message
Arthur Mello (artmello) wrote :
Revision history for this message
Arthur Mello (artmello) wrote :

We find two situations on gallery code that triggers the window height value issues.

The first one is setting the the window state to fullscreen after calling the show method from the QQuickView. The issue does not happen if the window state is changed before calling the show method.

The second one is when we call the method winId from the QQuickView before calling the show method. The issue also does not happen if the winId call happens after the show method.

I just attached a sample application that triggers the bug by calling the winId method before the show method.

On the MR attached to this bug we are changing the sequence of the calls on gallery to work around the issue.

Revision history for this message
Arthur Mello (artmello) wrote :

Also, when we trigger the issue, we saw output lines like these:

(...)
QUbuntuWindow::moveResize (this=0x145cbd8, x=0, y=0, w=768, h=1280)
QUbuntuWindow::moveResize (this=0x145cbd8, x=0, y=58, w=768, h=1222)
(...)

Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package gallery-app - 0.0.67+14.10.20140625.1-0ubuntu1

---------------
gallery-app (0.0.67+14.10.20140625.1-0ubuntu1) utopic; urgency=low

  [ Arthur Mello ]
  * Ensure the window is made fullscreen before it is shown, to work
    around an issue with calculating window coordinates. Also ensure
    that the window has been shown before querying for
    MAX_GL_TEXTURE_SIZE. (LP: #1332632)

  [ Ubuntu daily release ]
  * New rebuild forced
 -- Ubuntu daily release <email address hidden> Wed, 25 Jun 2014 19:08:54 +0000

Changed in gallery-app (Ubuntu):
status: New → Fix Released
Revision history for this message
kevin gunn (kgunn72) wrote :

assigning alf for mir. he actually worked on it his entire day today, although I don't think he found anything conclusive

Changed in mir:
assignee: nobody → Alexandros Frantzis (afrantzis)
Revision history for this message
kevin gunn (kgunn72) wrote :

ok, after some wrangling & fully verifying. I did flash image #88....and then took the latest mir along with unity-mir, platform-api, unity-system-compositor into the build
And the problem does occur so there's definitely something that change in the mir/unity-mir/platform-api stack to effect this.

Arthur Mello (artmello)
Changed in gallery-app:
status: In Progress → Fix Released
Revision history for this message
Alexandros Frantzis (afrantzis) wrote :

I have found the cause of this in Mir. Working on a fix.

Changed in mir:
status: New → In Progress
importance: Undecided → Critical
Revision history for this message
PS Jenkins bot (ps-jenkins) wrote :

Fix committed into lp:mir/devel at revision None, scheduled for release in mir, milestone Unknown

Changed in mir:
status: In Progress → Fix Committed
Changed in mir:
milestone: none → 0.4.0
Changed in mir:
status: Fix Committed → Fix Released
Revision history for this message
Daniel van Vugt (vanvugt) wrote :

mir (0.4.0+14.10.20140701.1-0ubuntu1) utopic; urgency=medium

Changed in mir (Ubuntu):
importance: Undecided → Critical
status: New → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

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