Loading a page in a new tab sometimes results in an unresponsive webview

[Víctor R. Ruiz]

Test case.
1. Open webrowser-app
2. Go to elpais.com or other sites with lots of contents.
3. Open a new tab.
4. Wait until it has loaded.
5. Scroll.
6. If scroll works fine, open a new tab and go to step 3.

Expected result.
- All the tabs can be scrolled.

Actual result.
- Eventually, the webview is blocked and cannot be scrolled, zoomed or have any type of interaction.

This has been tested in krillin with the overlay PPA.

current build number: 13
device name: krillin
channel: ubuntu-touch/rc-proposed/bq-aquaris.en

Start-Date: 2015-05-22 18:50:36
Commandline: apt-get dist-upgrade --yes
Install: telepathy-ofono-ril-mc-plugin:armhf (0.2+15.04.20150519.1-0ubuntu1, automatic)
Upgrade: qtdeclarative5-ubuntu-settings-components:armhf (0.6+15.04.20150409.1-0ubuntu1, 0.6+15.04.20150518-0ubuntu1), indicator-datetime:armhf (13.10.0+15.04.20150515-0ubuntu1, 13.10.0+15.04.20150521-0ubuntu1), indicator-power:armhf (12.10.6+15.04.20150515-0ubuntu1, 12.10.6+15.04.20150520-0ubuntu1), ubuntu-touch:armhf (1.221vivid2, 1.221vivid3), unity8-common:armhf (8.02+15.04.20150511-0ubuntu1, 8.02+15.04.20150518.1-0ubuntu2), systemd-shim:armhf (9-1bzr2, 9-1bzr3), powerd:armhf (0.16+15.04.20150507-0ubuntu1, 0.16+15.04.20150520-0ubuntu1), unity8-fake-env:armhf (8.02+15.04.20150511-0ubuntu1, 8.02+15.04.20150518.1-0ubuntu2), unity8:armhf (8.02+15.04.20150511-0ubuntu1, 8.02+15.04.20150518.1-0ubuntu2), unity8-private:armhf (8.02+15.04.20150511-0ubuntu1, 8.02+15.04.20150518.1-0ubuntu2), ubuntu-sdk-libs:armhf (1.221vivid2, 1.221vivid3), lxc-android-config:armhf (0.221, 0.223)
Error: Sub-process /usr/bin/dpkg returned an error code (1)
End-Date: 2015-05-22 18:50:46

[Olivier Tilloy (osomon)]

I have been able to observe this once in a large number of attempts on 2015-05-22. When that happened, it seemed as if the webview’s 'enabled' property was set to false, as it wasn’t reacting to any touch events (no scrolling, no pinch-to-zoom, no tapping to activate links…). Only that particular webview was unresponsive, the rest of the application responded well, and I could trigger a reload of the page from the chrome. Even after reloading and re-rendering, the page remained unresponsive. The renderer process didn’t seem to be frozen or anything like that. After closing that tab I wasn’t able to reproduce the issue again.

[Chris Coulson (chrisccoulson)]

I'm hitting something similar on desktop, but I don't know if it's the same issue. Does the app output a message to the console like this when it fails?

[0528/215057:ERROR:oxide_browser_main_parts.cc(156)] Not implemented reached in virtual gfx::Display oxide::{anonymous}::Screen::GetDisplayNearestWindow(gfx::NativeView) const

[Chris Coulson (chrisccoulson)]

http://bazaar.launchpad.net/~oxide-developers/oxide/oxide.trunk/revision/1099 fixes my issue on desktop.

[Olivier Tilloy (osomon)]

I don’t recall seeing that error in the console, however the drag event seems to be a common denominator, so it could very well be that it’s the same issue. Will need to be tested. Can we backport this fix to 1.8?

[Olivier Tilloy (osomon)]

@Víctor: have you seen this issue again? It might be that oxide 1.9 fixed it.

[Olivier Tilloy (osomon)]

I’m suspecting what might have been causing the original issue is the custom DirectionalDragArea code in webbrowser-app, that was copied over from unity8. If my suspicions are confirmed, then https://code.launchpad.net/~osomon/webbrowser-app/use-uitk-swipearea/+merge/290700 will fix the problem.

[Launchpad Janitor (janitor)]

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

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

  [ CI Train Bot ]
  * Resync trunk.

  [ Olivier Tilloy ]
  * Fine-tune the custom memory-pressure handler, from data gathered on
    several devices. (LP: #1576639)
  * Update translation template.

 -- Olivier Tilloy <email address hidden> Mon, 09 May 2016 17:56:03 +0000