Webview turns white after clicking on it

FWIW, I can't reproduce this with xenial + stable-phone-overlay running unity7

That was with oxide 1.15.7-0ubuntu1.

With oxide 1.16.7-0ubuntu1 the pages don't even load, and a SIGILL is received almost immediately:

http://paste.ubuntu.com/23061690/

Unless this is fixed, Online Accounts will be completely broken in Yakkety.

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

It is probably a duplicate of https://bugs.launchpad.net/oxide/+bug/1613258 which has been fixed by now.

oxide-qt 1.16.9-0ubuntu1 is now in yakkety and fixes the SIGILL issue (bug #1613258).
Does the original persist with this new version?

Yes, it's not possible to add an account to yakkety's Ubuntu Online Accounts because of this issue (tested with yesterday's daily iso which has oxide-qt 1.16.9-0ubuntu1).

I don't think that this bug is a duplicate of 1618589, because there's no crash here (with oxide 1.16.9-0ubuntu1).

I did some testing and verified that oxide works fine in yakkety when used by online-accounts-ui (which is the UI we use in unity8), the problem occurs only with signon-ui (used in unity7). The problem happens when the webview gains focus: if you just roll your mouse wheel over it, it scrolls properly; but if you click on it, or just press the TAB key a few times until the webview gains focus, then it disappears and this gets printed on the terminal:

OxideQQuickWebContext: Cannot set hostMappingRules once the context is in use
OxideQQuickWebContext: devtoolsBindIp was set to an invalid value. It must be set to a valid IPv4 or IPv6 address
OxideQQuickWebContext: devtoolsPort was set to an invalid value. It must be set between 1024 and 65535
OxideQQuickUserScript: url is a construct-only parameter
OxideQQuickUserScript: url is a construct-only parameter
OxideQQuickUserScript: url is a construct-only parameter
OxideQQuickUserScript: url is a construct-only parameter
OxideQQuickWebContext::Cannot set sessionCookieMode once the context is in use
OxideQQuickWebContext: Cannot set maxCacheSizeHint once the context is in use
OxideQQuickWebContext:: Cannot set cachePath once the context is in use
OxideQQuickWebContext: Cannot set dataPath once the context is in use
qml: Loaded 9 UA override(s) from file:///usr/lib/x86_64-linux-gnu/qt5/qml/Ubuntu/Web/ua-overrides-desktop.js

It looks like oxide is reinitializing its context when it gets activated.

(the main difference between signon-ui and online-accounts-ui is that the former is being embedded (via XEMBED) into the Gtk-based unity-control-center)

Either those warnings in comment 8 are a red herring, or it's an application issue - there are no call sites within Oxide to the APIs that trigger those warnings.

Same behaviour occurs with oxide 1.14.9-0ubuntu1 and 1.13.6-0ubuntu1.

I'm now trying to verify whether this might be due to some change in Qt 5.5 -> 5.6; I'm trying to rollback my yakkety installation to Qt 5.5, but it's far from being a trivial operation...

I gave up with trying on Qt 5.5, because it requires packages and QML modules to be updated and recompiled.

Instead, I checked out Qt 5.6, from upstream git, built it, then installed the oxide and various Ubuntu QML modules into it by creating symlinks:

    ln -s /usr/lib/x86_64-linux-gnu/qt5/qml/Ubuntu/ ~/src/git/qt5/qtbase/qml/ # UITK
    ln -s /usr/lib/x86_64-linux-gnu/qt5/qml/com ~/src/git/qt5/qtbase/qml/ # for oxide

Then I rebuilt signon-ui against this newly built Qt version and... surprise, it works fine. I still see the same oxide warnings when the webview gets focused, so that hints at a problem within Oxide itself, but at least the view doesn't become blank and the account creation can proceed.

I'll now try to identify which are the changes that trigger the bug; it might take some time, as I've no idea on what to look for.

It turns out we've been extremely lucky, in that the commit which fixes (or hides?) this bug landed in Qt 5.6 just yesterday:

  https://codereview.qt-project.org/#/c/153945/

I've tried building Qt with and without that commit, and indeed it makes a difference.

This bug was fixed in the package qtbase-opensource-src - 5.6.1+dfsg-3ubuntu4~6

---------------
qtbase-opensource-src (5.6.1+dfsg-3ubuntu4~6) yakkety; urgency=medium

  [ Timo Jyrinki ]
  * debian/patches/Make-QDBusConnectionPrivate-relaySignal-be-called-in.patch:
    - Antoher DBus fix needed for telephony-service (LP: #1620945)
  * debian/patches/Fix-gcc-Wsuggest-override-warning-on-Q_OBJECT.patch
    debian/patches/Fix-the-GCC-version-supporting-Wsuggest-override.patch:
    - Fix GCC -Wsuggest-override warning on Q_OBJECT (LP: #1619483)
  * debian/patches/Fix-parsing-of-tzfile-5-POSIX-rule-zone-names-with-b.patch:
    - Fix parsing of rule zone names for certain time zones (LP: #1622089)
  * debian/patches/Avoid-artifacts-when-hiding-or-closing-a-QOpenGLWidg.patch
    debian/patches/QtWidgets-Send-show-hide-event-to-children-on-restor.patch:
    - Fix event sending to children, hurting Oxide-Qt use on desktop
      (LP: #1613670)
  * Disable QStaticText tests for now (QTBUG-55653)

 -- Timo Jyrinki <email address hidden> Mon, 12 Sep 2016 05:42:31 +0000

Unfortunately this is not fixed: I'm using 5.6.1+dfsg-3ubuntu5~1 and the webview still turns white after clicking on it.

I've done some more tests, and it now seems to me that we also need commit 6371b208a9e55845090dcd34234e314c6587c105 in qtdeclarative.

I've created https://bileto.ubuntu.com/#/ticket/1997 for qtdeclarative+qtdeclarative-gles.

In yakkety UNAPPROVED queue now.

This bug was fixed in the package qtdeclarative-opensource-src - 5.6.1-7ubuntu2~1

---------------
qtdeclarative-opensource-src (5.6.1-7ubuntu2~1) yakkety; urgency=medium

  * debian/patches/Revert-Remove-this-piece-of-code.patch:
    - Cherry-pick from Qt 5.6.2 (LP: #1613670)

 -- Timo Jyrinki <email address hidden> Mon, 26 Sep 2016 13:13:20 +0000