38450 2010-05-02 23:36:12 -0700 [Qt] Problem loading multiple pages at once. 2014-01-29 07:46:11 -0800 1 1 1 Unclassified WebKit New Bugs 420+ PC Windows XP RESOLVED INVALID Qt, QtTriaged P5 Critical --- 1 allmarx webkit-unassigned allan.jensen allmarx andersca cmarcelo hausmann jturcotte kent.hansen markus oldest_to_newest 220028 0 allmarx 2010-05-02 23:36:12 -0700 If you try to load two pages at the same time, on two separate QWebViews, you run into some very strange issues. I think this may be some annoying threading issue deep within the core, but I'm a noob and don't really know. Here is a quick test case that makes two QWebViews that each load digg.com. It logs the output in two QTextEdit windows. ------------- main.cpp ------------- #include <QtGui/QApplication> #include "logger.h" int main(int argc, char *argv[]) { QApplication a(argc, argv); for (int i = 0; i < 2; ++i) { Logger *log = new Logger(); QWebView *web = new QWebView(); QObject::connect(web, SIGNAL(loadFinished(bool)), log, SLOT(onLoadFinished(bool))); web->load(QUrl("http://digg.com")); log->show(); } return a.exec(); } ------------ logger.h ------------ #ifndef LOGGER_H #define LOGGER_H #include <QTextEdit> #include <QWebView> #include <QWebFrame> class Logger : public QTextEdit { Q_OBJECT public: Logger(QWidget *p = 0) : QTextEdit(p) {} public slots: void onLoadFinished(bool ok) { if (ok) this->append("Load successful"); else this->append("Load failed"); QString html = ((QWebView*)sender())->page()->mainFrame()->toHtml(); int htmlSize = (html.isNull() || html.isEmpty()) ? 0 : html.length(); this->append(QString("Html size: %1").arg(htmlSize)); } }; #endif // LOGGER_H -- -- Expected Output: -- *Log 1 and 2* Load successful Html size: 92735 -- Actual Output: -- *Log 1* Load successful Html size: 92735 *Log 2* Load successful Html size: 2057 Load successful Html size: 92571 Load successful Html size: 92735 - Other notes: This appears to work as expected for google.com (your results may vary), but digg.com and other websites will fail. Not sure what the common factor is. 220036 1 markus 2010-05-03 00:11:46 -0700 Which Qt version are you using? 220207 2 allmarx 2010-05-03 11:25:53 -0700 4.6.2 220363 3 allmarx 2010-05-03 16:37:40 -0700 Okay, this is an obvious issue with the JavaScript core. With JS disabled, the expected results are obtained. However, permanently disabling JS is an ugly hack that is not an option for many applications. This should perhaps be the #1 issue to fix for QtWebKit in my opinion. When two separate QWebViews can't even load a page and parse JavaScript simultaneously without disrupting each other in subtle ways, how can we expect tabbed browsers to operate correctly? 221602 4 kent.hansen 2010-05-06 03:21:26 -0700 I can reproduce on Linux against trunk (r58872). 221721 5 kent.hansen 2010-05-06 09:21:43 -0700 digg.com creates several iframes. Every time a frame has loaded, this is reported to FrameLoaderClientQt. And FrameLoaderClientQt::postProgressFinishedNotification() decides to emit loadFinished() for more than one frame. Modifying the testcase to connect to view->page()->mainFrame()'s loadFinished() signal reveals that it's the "Load successful, Html size: 2057" that comes from the mainframe of one view, the two other signals are due to other frames. 221869 6 allmarx 2010-05-06 12:01:54 -0700 Not saying your hypothesis is wrong, in fact it makes a lot of sense, but just wondering how come one of the Loggers only emits 1 load while the other does many? Theoretically they are loading the same page...? 221877 7 allmarx 2010-05-06 12:08:37 -0700 Also I think the HTML size 2057 is === to an empty string (iirc the MAX_STRING "buffer" is like 2058 or something?), because when I try to print it, it's blank. 227295 8 56371 kent.hansen 2010-05-18 07:28:37 -0700 Created attachment 56371 Gtk testcase Similar testcase for Gtk. Output: 0x960a808 load status changed: 0 0x960a8e0 load status changed: 0 0x960a808 load status changed: 1 0x960a8e0 load status changed: 1 0x960a8e0 load status changed: 2 load_finished_cb(0x960a8e0, 0x9625b80) 0x960a808 load status changed: 3 0x960a8e0 load status changed: 3 load_finished_cb(0x960a8e0, 0x963c2f0) 0x960a808 load status changed: 2 load_finished_cb(0x960a808, 0x9621f80) So load-finished is emitted twice for one of the views. And the load-status change order seems fishy for one of the views too (WEBKIT_LOAD_FINISHED before WEBKIT_LOAD_FIRST_VISUALLY_NON_EMPTY_LAYOUT). With only one view this is the output (which is fine): 0x9bdb808 load status changed: 0 0x9bdb808 load status changed: 1 0x9bdb808 load status changed: 3 0x9bdb808 load status changed: 2 load_finished_cb(0x9bdb808, 0x9bf3380) Either Qt and Gtk are both doing something wrong, or the bug is deeper in WebCore. For sure, WebCore/loader/ProgressTracker.cpp is calling finalProgressComplete() more than once; this is what causes the multiple loadFinished() / load-finished signals. ProgressTracker is associated with a Page, not Frame, so that seems wrong. For what it's worth, it looks like the page is eventually loading correctly in both views, it's just the progress notification that's incorrect. Could it be that digg lazily creates some frames/content from JS, and the WebKit loader can't anticipate this? Who wants to try it with a WebView on Mac to see how many times a WebViewProgressFinishedNotification is posted? 782387 9 allan.jensen 2012-12-04 01:54:55 -0800 I am pretty sure this is expected behavior. A scripted webpage can finish loading, then fire a timeout that causes more content to be required to be loaded, and then finish loading that, finishing a second time. Pages that dynamically loads content is going to finish loading several times. 782394 10 jturcotte 2012-12-04 02:08:41 -0800 (In reply to comment #9) > I am pretty sure this is expected behavior. A scripted webpage can finish loading, then fire a timeout that causes more content to be required to be loaded, and then finish loading that, finishing a second time. > > Pages that dynamically loads content is going to finish loading several times. loadFinished should only be emitted at the end of provisional load, there should be no signal after the initial load. Unless if a new subframe is created, which produces the behavior explained in comment #5. 56371 2010-05-18 07:28:37 -0700 2010-05-18 07:28:37 -0700 Gtk testcase main.c text/x-csrc 1639 kent.hansen I2luY2x1ZGUgPGd0ay9ndGsuaD4KI2luY2x1ZGUgPHdlYmtpdC93ZWJraXQuaD4KCnZvaWQgbG9h ZF9maW5pc2hlZF9jYihXZWJLaXRXZWJWaWV3ICp3ZWJfdmlldywKICAgICAgICAgICAgICAgICAg ICAgIFdlYktpdFdlYkZyYW1lICpmcmFtZSwKICAgICAgICAgICAgICAgICAgICAgIGdwb2ludGVy IHVzZXJfZGF0YSkKewogICAgZnByaW50ZihzdGRvdXQsICJsb2FkX2ZpbmlzaGVkX2NiKCVwLCAl cClcbiIsIHdlYl92aWV3LCBmcmFtZSk7Cn0KCnZvaWQgbm90aWZ5X2xvYWRfc3RhdHVzX2NiKFdl YktpdFdlYlZpZXcgKndlYl92aWV3LAogICAgICAgICAgICAgICAgICAgICAgICAgICBHUGFyYW1T cGVjICphcmcxLAogICAgICAgICAgICAgICAgICAgICAgICAgICBncG9pbnRlciB1c2VyX2RhdGEp CnsKICAgIGZwcmludGYoc3Rkb3V0LCAiJXAgbG9hZCBzdGF0dXMgY2hhbmdlZDogJWRcbiIsIHdl Yl92aWV3LCB3ZWJraXRfd2ViX3ZpZXdfZ2V0X2xvYWRfc3RhdHVzICh3ZWJfdmlldykpOwp9Cgpp bnQKbWFpbiAoaW50IGFyZ2MsIGNoYXIqIGFyZ3ZbXSkKewogICAgZ3RrX2luaXQgKCZhcmdjLCAm YXJndik7CiAgICBpZiAoIWdfdGhyZWFkX3N1cHBvcnRlZCAoKSkKICAgICAgICBnX3RocmVhZF9p bml0IChOVUxMKTsKCiAgICBpbnQgaTsKICAgIGZvciAoaSA9IDA7IGkgPCAxOyArK2kpIHsKICAg ICAgICAvKiBDcmVhdGUgdGhlIHdpZGdldHMgKi8KICAgICAgICBHdGtXaWRnZXQgKm1haW5fd2lu ZG93ID0gZ3RrX3dpbmRvd19uZXcgKEdUS19XSU5ET1dfVE9QTEVWRUwpOwogICAgICAgIEd0a1dp ZGdldCAqc2Nyb2xsZWRfd2luZG93ID0gZ3RrX3Njcm9sbGVkX3dpbmRvd19uZXcgKE5VTEwsIE5V TEwpOwogICAgICAgIEd0a1dpZGdldCAqd2ViX3ZpZXcgPSB3ZWJraXRfd2ViX3ZpZXdfbmV3ICgp OwoKICAgICAgICAvKiBQbGFjZSB0aGUgV2ViS2l0V2ViVmlldyBpbiB0aGUgR3RrU2Nyb2xsZWRX aW5kb3cgKi8KICAgICAgICBndGtfY29udGFpbmVyX2FkZCAoR1RLX0NPTlRBSU5FUiAoc2Nyb2xs ZWRfd2luZG93KSwgd2ViX3ZpZXcpOwogICAgICAgIGd0a19jb250YWluZXJfYWRkIChHVEtfQ09O VEFJTkVSIChtYWluX3dpbmRvdyksIHNjcm9sbGVkX3dpbmRvdyk7CgogICAgICAgIGdfc2lnbmFs X2Nvbm5lY3QgKEdfT0JKRUNUICh3ZWJfdmlldyksICJsb2FkLWZpbmlzaGVkIiwgR19DQUxMQkFD SyAobG9hZF9maW5pc2hlZF9jYiksIE5VTEwpOwogICAgICAgIGdfc2lnbmFsX2Nvbm5lY3QgKEdf T0JKRUNUICh3ZWJfdmlldyksICJub3RpZnk6OmxvYWQtc3RhdHVzIiwgR19DQUxMQkFDSyAobm90 aWZ5X2xvYWRfc3RhdHVzX2NiKSwgTlVMTCk7CgogICAgICAgIC8qIE9wZW4gYSB3ZWJwYWdlICov CiAgICAgICAgd2Via2l0X3dlYl92aWV3X2xvYWRfdXJpIChXRUJLSVRfV0VCX1ZJRVcgKHdlYl92 aWV3KSwgImh0dHA6Ly9kaWdnLmNvbSIpOwoKICAgICAgICAvKiBTaG93IHRoZSByZXN1bHQgKi8K ICAgICAgICBndGtfd2luZG93X3NldF9kZWZhdWx0X3NpemUgKEdUS19XSU5ET1cgKG1haW5fd2lu ZG93KSwgODAwLCA2MDApOwogICAgICAgIGd0a193aWRnZXRfc2hvd19hbGwgKG1haW5fd2luZG93 KTsKICAgIH0KICAgIGd0a19tYWluICgpOwoKICAgIHJldHVybiAwOwp9Cg==