[Webkit-unassigned] [Bug 82995] [Qt] Delayed availability of QtWebFrame::url() and confusing semantics of QtWebPage::loadFinished()

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=82995


Bruno Abinader <bruno.abinader at basyskom.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bruno.abinader at basyskom.com




--- Comment #1 from Bruno Abinader <bruno.abinader at basyskom.com>  2012-06-21 06:49:52 PST ---
Have you tried "urlChanged" signal from QWebFrame? It seems the most reliable way to know when a URL is actually set.

(In reply to comment #0)
> Between QtWebKit 2.1 and 2.2 the following was change was made to QtWebKit: https://bugs.webkit.org/show_bug.cgi?id=41165.
> 
> This changes the availability of QtWebFrame::url() such that at the time replyFinished() is fired by a custom QNetworkAccessManager, the current frame does not yet have a URL (and seemingly doesn't have a document(), hence why it doesn't have a url()).
> 
> This has manifested itself in the capybara-webkit driver for Ruby: http://git.io/at1AuQ#L189.
> 
> I began to put together a workaround that would delay processing of the QNetworkReply until loadFinished() was fired by the custom QWebPage.  However, it seems that loadFinished() is fired by QWebPage before QWebFrame::url() is available as well.  In fact, if you bind to loadFinished() of QWebPage::currentFrame(), it fires after loadFinished() of the QWebPage has fired.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.