Webview turns black for a fraction of a second when it’s unhidden

[JkB]

When taking an Action, for example pop a Page (e.g. Settings in webbrowser app) the webview turns black for part of a second.
If there is more content in a website or javascript running, this effect can last for up to a second.

Is that a known problem?

[Olivier Tilloy (osomon)]

I can observe that on my krillin running the latest rc-proposed image.

[JkB (joergberroth)]

Hello,

I think one should readd oxide to this, as it occures in other oxide
webviews also.

It seems that oxide puts a black background before being able to rebuild
the page.

Am 2015-10-08 um 23:17 schrieb Olivier Tilloy:
> I can observe that on my krillin running the latest rc-proposed image.
>
> ** Also affects: webbrowser-app (Ubuntu)
> Importance: Undecided
> Status: New
>
> ** Changed in: webbrowser-app (Ubuntu)
> Status: New => Confirmed
>
> ** Changed in: oxide
> Status: New => Invalid
>

[Olivier Tilloy (osomon)]

Do you mean that you are able to observe this in a QML app with a plain com.canonical.Oxide.WebView ?
If so, a standalone example would be very welcome.

[JkB (joergberroth)]

Hi, Yes.

Right now I do not have a standalone, but while working on lp:unav
I encountered this for our Oxide.Webview also.

If you have unav installed try:
- Start the app and go for a HeaderAction like info or settings and then
go back: it will behave as in webbrowser-app. You will encounter a black
screen for part of a second.
- If I am on a route (meaning that there is a lot of active js content
in the webview) this behaviour extents to up to a second.

It seems that this behaviour falls back to oxide.

I will try to get a standalone example as soon as i have a bit more
spare time.

Am 2015-10-09 um 11:11 schrieb Olivier Tilloy:
> Do you mean that you are able to observe this in a QML app with a plain com.canonical.Oxide.WebView ?
> If so, a standalone example would be very welcome.
>

[Chris Coulson (chrisccoulson)]

Are you sure you mean "refocused", or do you mean that it's black when it's unhidden? If so, that's currently expected as we tear down the compositor for a hidden webview in order to free up memory.

I have a plan to make this a bit better, particularly for the switching tabs case in the browser where we'll probably recycle the compositor rather than tearing one down and creating a new one.

[JkB (joergberroth)]

Hi,
maybe "unhidden" is the right word if it describes an in app "hiding" of
the webview - by another page in the stack for example.
I am not into how this is handled, but it sounds like we talk about the
same effect ;-).
A quick fix could be just to not paint it black but e.g. in background
color as this would increase user experience recognizably for states
where it takes a while to get contents back (creating a new one?!).

Looking forward to your improvement.

Am 2015-10-20 um 22:06 schrieb Chris Coulson:
> Are you sure you mean "refocused", or do you mean that it's black when
> it's unhidden? If so, that's currently expected as we tear down the
> compositor for a hidden webview in order to free up memory.
>
> I have a plan to make this a bit better, particularly for the switching
> tabs case in the browser where we'll probably recycle the compositor
> rather than tearing one down and creating a new one.
>

[Olivier Tilloy (osomon)]

I set the importance to high as, in the current state of affairs, this prevents us from providing a smooth animation when switching tabs in the browser.

[Olivier Tilloy (osomon)]

A simple (simplistic) workaround consists in delaying the switch between one webview and the other. Something like that (for two webviews):

Item {
    WebView {
        anchors.fill: parent
        visible: (current == 0) || (next == 0)
        z: (current == 0) ? 1 : 0
    }

    WebView {
        anchors.fill: parent
        visible: (current == 1) || (next == 1)
        z: (current == 1) ? 1 : 0
    }

    property int current: 0
    property int next: -1

    Timer {
        id: switchTimer
        interval: 100
        onTriggered: {
            current = next
            next = -1
        }
    }

    onSwitchWebviewRequested: {
        next = (current + 1) % 2
        switchTimer.restart()
    }
}

This is only a workaround though, fixing the root issue in oxide would be preferable of course. Until then, I’ll see if I can implement that workaround in the browser.

[Launchpad Janitor (janitor)]

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

---------------
webbrowser-app (0.23+16.04.20151124-0ubuntu1) xenial; urgency=medium

  * Multiple changes to improve the tab switching animation. The biggest
    remaining issue is bug #1502675, which is worked around here until
    it is properly addressed in oxide. (LP: #1502675)

 -- Olivier Tilloy <email address hidden> Tue, 24 Nov 2015 12:03:50 +0000