[webkit-qt] progressive rendering in a QML browser

[Olivier Tilloy]

Olivier Tilloy a écrit :
> Olivier Tilloy a écrit :
>> […]
>>>
>>> Just quickly ran a test with MiniBrowser on my desktop and for me with a
>>> clean cache even heavy pages like nytimes.com <http://nytimes.com> start
>>> to render when the progress bar is at about 50% completion. Although
>>> this probably varies depending on network and HW speed.
>>>
>>> This is comparably similar behaviour as you would experience with Safari
>>> on Mac.
>>
>> Thanks for the heads-up! So this means my build of QtWebKit somehow is
>> to blame.
>> I’m using libqt5webkit5-qmlwebkitplugin
>> 5.0.0-0ubuntu1~quantal1~test5~withdebug~gstabs~patches (from
>> https://launchpad.net/~canonical-qt5-edgers/+archive/qt5-proper) in
>> Ubuntu 12.10, which according to the source package is based off trunk
>> subversion revision 136242.
>
> A heads-up on my ongoing investigation of the issue: packages built from
> trunk (tested on 2013-03-28) work well, i.e. pages start rendering while
> still loading, whereas packages built from the latest release branch
> (git://gitorious.org/qt/qtwebkit.git, being prepared for 5.1.0) still
> exhibit the issue, i.e. pages are not rendered until fully loaded.
>
> So the problem persists in 5.0.1 and above, but has somehow been fixed
> in trunk. If I read the history of the release branch correctly, the
> latest import from trunk was revision
> 6a4a1d32e1d779548c726c4826cba9d69eb87601 (svn 136242), on 2012-11-30.
> Which makes me think that the issue (regression?) was fixed sometime
> between 2012-11-30 and 2013-03-28 in trunk (roughly 10000 commits).

It took a lot of bisecting, building and testing, but I finally nailed 
down the commit that fixed this regression: 
http://trac.webkit.org/changeset/136302.

This commit applies cleanly on top of the current qtwebkit release 
branch, and fixes progressive rendering (i.e. pages start to display 
before fully loaded).


> Any hint where I should be looking for what possibly fixed the issue?
>
> Do others observe the same issue with 5.0.1?

I’m kind of puzzled that no-one else has observed that, looks like an 
important regression to me.

Any chance commit 136302 can be backported to the release branch for 
5.1.0 ? What would be the process for this?

Cheers,

  Olivier