82995 2012-04-02 19:26:00 -0700 [Qt] Delayed availability of QtWebFrame::url() and confusing semantics of QtWebPage::loadFinished() 2014-02-03 03:20:31 -0800 1 1 1 Unclassified WebKit WebKit Qt 528+ (Nightly build) Unspecified Unspecified RESOLVED INVALID P3 Normal --- 0 matt webkit-unassigned bruno.abinader matt oldest_to_newest 594143 0 matt 2012-04-02 19:26:00 -0700 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. 654462 1 bruno.abinader 2012-06-21 06:49:52 -0700 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. 655102 2 matt 2012-06-21 18:09:42 -0700 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. 774984 3 matt 2012-11-25 08:40:42 -0800 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. 975430 4 jturcotte 2014-02-03 03:20:31 -0800 === 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.