RESOLVED INVALID 82995
[Qt] Delayed availability of QtWebFrame::url() and confusing semantics of QtWebPage::loadFinished() 
https://bugs.webkit.org/show_bug.cgi?id=82995
Summary [Qt] Delayed availability of QtWebFrame::url() and confusing semantics of QtW...
Matt Horan
Reported 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.
Attachments
Add attachment proposed patch, testcase, etc.
Bruno Abinader (history only)
Comment 1 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.
Matt Horan
Comment 2 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.
Matt Horan
Comment 3 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.
Jocelyn Turcotte
Comment 4 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.
Note You need to log in before you can comment on or make changes to this bug.