[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





--- Comment #2 from Matt Horan <matt at matthoran.com>  2012-06-21 18:09:42 PST ---
I had tried this as well, but it didn't seem to work as expected.  I'm still confused as to why loadFinished would fire before the URL is available.

(In reply to comment #1)
> 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.