Bug 85906 – [Qt][WK2] Remove delayed loadDidSucceed() signaling and m_deferedUrlToLoad from QQuickWebViewPrivate

• Component: WebKit2
• Status: RESOLVED FIXED

[alan]

No need to delay loading related activities, after http://trac.webkit.org/changeset/113172 , when WebView started being inherited from Flickable.

copied the discussion from here https://bugs.webkit.org/show_bug.cgi?id=84527#c3

"> (case 3, loadDidSucceed() implements some deferred loading success dispatching due to the delayed interaction engine construction. I looked at the original patch (bug 77111) and don't see any reasoning why success() is special in that case, and for example failed() is not. Commit log also states that page is suspended while I don't think it is, it's just that the suspend flag is turned on by default, so not sure why success() is treated differently here, unless I miss something, which could very well be the case. If this delaying logic could be omitted, we would end up even less d_func() calls in QtWebPageLoadClient(), provided that's the preferred direction.)

This delay was needed before the WebView became a subclass of Flickable because the instantiation of the internal Flickable happened in onComponentComplete and we needed to defer the emission of the success signal after the construction finished to prevent crashes in API tests, since almost all the unit tests depend on loadSuccess.

This delay can be omitted since WebView is a direct subclass of Flickable now."

[alan]

Created attachment 140766 [details]
Patch

[WebKit Review Bot]

Comment on attachment 140766 [details]
Patch

Clearing flags on attachment: 140766

Committed r116505: <http://trac.webkit.org/changeset/116505>

[WebKit Review Bot]

All reviewed patches have been landed.  Closing bug.