Scrolling on www.ceskenoviny.cz is very slow

[zubozrout]

Hello,
the Czech news site I am reading quite often was recently updated to a new design and as of this update scrolling on the site gets quite tricky. On some articles scrolling is almost impossible.

Now this is not the first site I find difficult to scroll on with an Ubuntu's web browser unfortunately, though it is usually the case of some heavy javascript ballast on the site I am sure.

The worst experience I am getting so far is on this article: http://www.ceskenoviny.cz/zpravy/francouzska-justice-obvinila-16letou-divku-z-planovani-teroru/1379685 where scrolling is very laggy and more or less only gets me either to the absolute top or the absolute bottom of the article, not anywhere in the middle. Slow scrolling won't help the issue.

Other articles like this one http://www.ceskenoviny.cz/zpravy/ceske-drahy-dostaly-pokutu-150-000-kc-za-chybejici-ceniky/1380181 feels only very laggy but not that bad from my experience.

I've been testing this on my Meizu MX4 with rc-proposed. Maybe this is only the device issue though I doubt it.

Is there something you can do about it?
Thank you very much.

[Launchpad Janitor (janitor)]

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

[Olivier Tilloy (osomon)]

I can observe the same issue when opening the link to the first article on my E4.5 running the latest rc-proposed. I’m observing that each touch input triggers a myriad of load events (if I’m at the bottom of the page and I scroll up, I can see the progress bar flash rapidly to indicate the something is being loaded off the network). I’m guessing this is the reason for the slowness. It looks like bad website design, rather than the browser’s fault in this case.
Do you have an android phone to compare how chrome on android behaves with this website? Maybe a user-agent override would "fix" the issue…

[zubozrout (zubozrout)]

@Olivier Tilloy: I've just asked my friend to test this on Android (Google Chrome) and was told the website (both the links I posted above) work just fine there, no problems with scrolling at all. I do no longer poses any Android (or non-Ubuntu) device so I can't test this on my own unfortunately :(.

[Olivier Tilloy (osomon)]

Just got my hands on an android phone, running a recent version of chrome (52), and I can confirm that scrolling of that same web page works fine. I’ll test the UA override hypothesis later today.

[zubozrout (zubozrout)]

@Olivier Tilloy: Thank you very much for testing this and for planning the UA override. I have no idea how to do that with my Ubuntu Phone :(.

[zubozrout (zubozrout)]

Also, I see I did not mention Liri web browser - the page works fine there as well.

[Olivier Tilloy (osomon)]

I’m seeing a stream of LoadCommitted events while scrolling on that page¹. In a simple oxide WebView though (without an address bar or any chrome), scrolling is almost smooth, so it seems this problem is browser specific. I’ve also tested with an Ubuntu.Web WebView and a dummy locationBarController (a red rectangle), and scrolling is reasonably smooth there too.

¹ http://www.ceskenoviny.cz/zpravy/francouzska-justice-obvinila-16letou-divku-z-planovani-teroru/1379685

[Olivier Tilloy (osomon)]

And a UA override doesn’t seem to make any change.

[Olivier Tilloy (osomon)]

In an attempt to nail down what may be the culprit I’ve commented out chunks of the browser code related to locationBarController and load events, but that hasn’t made the situation better. When scrolling on that page, I’m seeing the CPU usage of webbrowser-app skyrocket, so there’s something wrong, but I don’t know what yet.

[Olivier Tilloy (osomon)]

I’ve done some profiling on my arale and I’ve found out a few interesting things:

 - there’s an urlChanged handler in NavigationBar.qml¹ that’s triggered with every load event, and it’s costly

 - the loadEvent and titleChanged handlers in Browser.qml² are expensive too, because they cause updates to the HistoryModel that block the UI thread

 - the layout of the chrome/address bar depends too much on the 'loading'³ and 'loadProgress' properties of the webview, causing countless binding evaluations and re-layouts for each load event

All those observations cause a tremendous slowdown on that specific page because scrolling triggers LoadCommitted events. I’m not sure why those events are triggered at all, but I’m sure the browser can be improved to not grind to a halt when that happens.

¹ https://bazaar.launchpad.net/~phablet-team/webbrowser-app/trunk/view/head:/src/app/webbrowser/NavigationBar.qml#L142
² https://bazaar.launchpad.net/~phablet-team/webbrowser-app/trunk/view/head:/src/app/webbrowser/Browser.qml#L1276
³ https://bazaar.launchpad.net/~phablet-team/webbrowser-app/trunk/view/head:/src/app/webbrowser/NavigationBar.qml#L125

[zubozrout (zubozrout)]

@Olivier Tilloy: Wow, quick and awesome work :), thank you. I would expect there are other websites affected by this behaviour based on your observations so if this could be fixed I hope it will not only help to resolve problems with this specific page but other sites as well.

[zubozrout (zubozrout)]

Hmm, just found another page that doesn't work that well in Ubuntu's browser: https://www.paradoxplaza.com/cities-skylines-deluxe?___store=eu

[Olivier Tilloy (osomon)]

> the layout of the chrome/address bar depends too much on the 'loading'
> and 'loadProgress' properties of the webview, causing countless
> binding evaluations and re-layouts for each load event

When loadCommitted events are emitted while scrolling on that page on ceskenoviny.cz, I have verified that the value of 'loadProgress' doesn’t change. The progress bar flashes as a result of the value of 'loading' changing, but its value is not changing.

[Olivier Tilloy (osomon)]

Another interesting observation with http://www.ceskenoviny.cz/zpravy/francouzska-justice-obvinila-16letou-divku-z-planovani-teroru/1379685: as soon as I scroll on this page (by dragging a finger on a phone or using the mouse scroll wheel on desktop), the contents of the title element change, so we get a huge number of titleChanged events (which in turn may trigger a history db update). I have verified that the same happens in chromium, so it’s not an oxide/webbrowser-app bug, more likely a website bug. Still, we should try and handle this gracefully.

[Launchpad Janitor (janitor)]

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

---------------
webbrowser-app (0.23+17.04.20161024.1-0ubuntu1) zesty; urgency=medium

  [ Andrew Hayzen ]
  * Fix for issue where many tabs causes close button to overlap other
    tabs (LP: #1473630)
  * When page has started, stopped, redirected or errored clear cache for
    history update - which prevents incorrect titles in being set
    (LP: #1603835)
  * Add autopilot tests javascript dialogs to webbrowser and
    webapp-container - alertDialog, beforeUnloadDialog, confirmDialog and
    promptDialog (LP: #1633040)
  * Add user-agent override to display the new twitter mobile interface
    (LP: #1577834)

  [ Florian Boucault ]
  * Improved startup time by 800ms by delaying QML compilation and making
    it asynchronous

  [ Olivier Tilloy ]
  * Replace chromium version in UA overrides at runtime, not at build
    time (LP: #1599695)
  * Initial support for generating a snap package for webbrowser-app
    (LP: #1629009)
  * Do not persist references to incognito downloads on disk
    (LP: #1625519)
  * Increase test coverage (to 97.5%) for DownloadsModel (LP: #1534102)
  * Various performance optimizations linked to load events
    (LP: #1611680)
  * Ensure a tab is loaded when re-opened (LP: #1632246)
  * Fix drag'n'drop of bookmarks within the new tab view (LP: #1584868)
  * Work around a limitation in the sound and microphone policy groups
    to "fix" sound in yakkety an zesty (LP: #1632620)

 -- Olivier Tilloy <email address hidden> Mon, 24 Oct 2016 13:51:59 +0000