Bug 82995 - [Qt] Delayed availability of QtWebFrame::url() and confusing semantics of QtWebPage::loadFinished()
Summary: [Qt] Delayed availability of QtWebFrame::url() and confusing semantics of QtW...
Status: RESOLVED INVALID
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKit Qt (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P3 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-04-02 19:26 PDT by Matt Horan
Modified: 2014-02-03 03:20 PST (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Matt Horan 2012-04-02 19:26:00 PDT
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.
Comment 1 Bruno Abinader (history only) 2012-06-21 06:49:52 PDT
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.
Comment 2 Matt Horan 2012-06-21 18:09:42 PDT
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.
Comment 3 Matt Horan 2012-11-25 08:40:42 PST
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.
Comment 4 Jocelyn Turcotte 2014-02-03 03:20:31 PST
=== 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.