The top panel is not restored after toggling full screen off

[Olivier Tilloy]

I’m implementing fullscreen mode for the browser application, and I’m seeing two issues, which can be reliably reproduced with the following piece of QML:

import QtQuick 2.0
import QtQuick.Window 2.1
import Ubuntu.Components 0.1
Window {
  id: window
  Button {
    anchors.centerIn: parent
    text: "toggle fullscreen"
    onClicked: window.visibility = (window.visibility == Window.FullScreen ? Window.AutomaticVisibility : Window.FullScreen)
  }
}

Issue #1: when toggling fullscreen on, the top panel is hidden as expected, and consequently the coordinates of the window change on screen, but the contents of the window are not redrawn, so in the example above tapping the button has no effect (one needs to tap slightly above it to activate it)

Issue #2: when toggling fullscreen off, the top panel is not restored.

[Michał Sawicz (saviq)]

The surface dimensions are currently handled in qtubuntu, but this will change with the qt compositor landing, at which point it's unity8 that will make this happen.

[Bill Filler (bfiller)]

this one is kind of critical for the browser, as we can now fullscreen a youtube video and the experience is kind of bad with this bug

[Launchpad Janitor (janitor)]

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

[Launchpad Janitor (janitor)]

This bug was fixed in the package webbrowser-app - 0.23+14.10.20140620-0ubuntu1

---------------
webbrowser-app (0.23+14.10.20140620-0ubuntu1) utopic; urgency=low

  [ Olivier Tilloy ]
  * Re-enable the geolocation permission request dialog, now that it is
    implemented in oxide. Fix it in the webkit-based webapp container.
    (LP: #1182658)
  * Temporarily work around bug #1328839 in qtubuntu by not toggling
    fullscreen on the window on devices. Once the Qt compositor work
    lands (scheduled for mid July), the bug should be resolved and this
    workaround can be removed. (LP: #1328839)
 -- Ubuntu daily release <email address hidden> Fri, 20 Jun 2014 09:27:06 +0000

[Gerry Boland (gerboland)]

We've not tested QtMir/Unity8 handling an app changing to fullscreen and then back to normal, so that needs to be done.

Also need to check qtubuntu allows a client app to ask for fullscreen and back again to normal.

[Florian Boucault (fboucault)]

qtubuntu's code looks fine from a quick glance

[Daniel d'Andrada (dandrader)]

Probably another instance of the same bug:

1- launch calendar (notice that calendar is a non-fullscreen app)
2- switch to dash
3- go to spread
4- kill calendar from the terminal
5- tap on the (dead) calendar in the spread

expected outcome:
calendar is restarted as non-fullscreen

actual outcome:
calendar is restarted as fullscreen

[Olivier Tilloy (osomon)]

I just tested reverting the workaround in webbrowser-app now that the Qt compositor has landed, and while the situation has improved a bit, issue #2 as described in the original report is still present: when exiting fullscreen mode, the top panel is not restored.

[Robert Carr (robertcarr)]

The start of the problem is in platform API, where there is no way to requestleaving fullscreen!

[Robert Carr (robertcarr)]

With https://code.launchpad.net/~mir-team/platform-api/support-state-changing/+merge/235545 and https://code.launchpad.net/~mir-team/qtubuntu/support-state-changing/+merge/235546

the example QML snippet functions correctly.

[kevin gunn (kgunn72)]

@bfiller
currently this bug has a workaround in place it seems.
so is this really rtm14 ??

[Olivier Tilloy (osomon)]

@Kevin: we had a workaround in place in webbrowser-app indeed, but the bug has now been fixed in platform-api and qtubuntu, so I’ve submitted a change in webbrowser-app to remove the workaround. With that, I guess it’s fine if we keep the rtm14 tag.