[Qt] Delayed availability of QtWebFrame::url() and confusing semantics of QtWebPage::loadFinished()

• Component: WebKit Qt
• Status: RESOLVED INVALID

[Matt Horan]

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.

[Bruno Abinader (history only)]

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.

[Matt Horan]

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.

[Matt Horan]

It actually looks like bug 32723 is to blame for this.  QWebFrame::url() returns an invalid URL for iframes, and the urlChanged signal is never fired.

[Jocelyn Turcotte]

=== Bulk closing of Qt bugs ===

If you believe that this bug report is still relevant for a non-Qt port of webkit.org, please re-open it and remove [Qt] from the summary.

If you believe that this is still an important QtWebKit bug, please fill a new report at https://bugreports.qt-project.org and add a link to this issue. See http://qt-project.org/wiki/ReportingBugsInQt for additional guidelines.