Transparent confirmation dialog

[Víctor R. Ruiz]

Test case.
- Open attached testobu.html simple test case in webbrowser-app.
- Tap on text entry box to select it for input.
- Notice confirmation dialog pops up, as well as keyboard.
- Confirmation dialog background is pushed upward off screen by OSK, and an ugly transparent effect is shown.

Expected result.
- A confirmation dialog is displayed correctly, so the user can stay in the confirmation page.

Actual result.
- The confirmation dialog is displayed, but transparent. See attached video. If the OSK is moved to the bottom, the confirmation dialog background is displayed.

com.canonical.payui_15.01.120_armhf.click
current build number: 260
device name: krillin
channel: ubuntu-touch/ubuntu-rtm/14.09-proposed

[Olivier Tilloy (osomon)]

I’m not seeing the issue as observed in the attached video when opening the example page in the browser.

In the browser, the confirmation popup behaves as expected, with its semi-transparent background overlaid on top of the entire app, as expected.

The issue seems to be in applications embedding a webview. In the case of pay-ui, the code is there: http://bazaar.launchpad.net/~unity-api-team/pay-ui/first-branch/view/head:/app/ui/UbuntuPurchaseWebkit.qml.

[dobey (dobey)]

Olivier, I replicated this issue in webbrowser-app using the attached HTML file. The keyboard opens up and pushes the dialog up off the screen. The code in pay-ui which adds these dialogs to the web view, is exactly the same as the code which does so in webbrowser-app. We simply set the properties on the WebView component, using the exact same .qml that was copied out of webbrowser-app to make the dialogs work at all there.

It looks like this behaves correctly on Vivid, but it is broken on RTM. Can we see about possibly getting whatever fixes this, backported to RTM perhaps?

[Olivier Tilloy (osomon)]

Indeed, I can reproduce the bug on RTM. Re-targetting to ubuntu-rtm.

[Olivier Tilloy (osomon)]

> It looks like this behaves correctly on Vivid, but it is broken on RTM.
> Can we see about possibly getting whatever fixes this, backported to
> RTM perhaps?

From a quick glance at the code differences between RTM and vivid, I can’t tell which change fixed this.
I’m thinking that it might actually be a UITK update that fixed it.