Comment 10 for bug 1611680

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