ASSIGNED14171
DOM not always available in didFinishLoadForFrame if multiple WebViews are busy loading (Colloquy doesn't display chat messages)
https://bugs.webkit.org/show_bug.cgi?id=14171
Summary DOM not always available in didFinishLoadForFrame if multiple WebViews are bu...
Alexander Kempgen
Reported 2007-06-15 09:33:36 PDT
Sometimes Colloquy's webviews are just blank when loading (= when joining a chat room). And also this problem is appearing a lot more often (not all the time though) for everyone with the Safari 3 beta than with Tiger's original WebKit. Colloquy's trac ticket on this bug is in the URL field.
Attachments
Almost working patch (516 bytes, patch)
2007-07-17 16:03 PDT, Timothy Hatcher
no flags
Brady Eidson
Comment 1 2007-06-16 09:22:22 PDT
a workaround, in the meantime, is to type "/reload style" in one of these blank webviews.
Mark Rowe (bdash)
Comment 2 2007-07-17 00:47:17 PDT
A workaround was landed in Colloquy's SVN in r3708. It mentions that there is likely something that needs fixed in WebKit, but doesn't provide any specifics... Does anyone know what the issue is here?
Timothy Hatcher
Comment 3 2007-07-17 11:23:17 PDT
I am working on the WebKit issue.
Timothy Hatcher
Comment 4 2007-07-17 16:02:32 PDT
The issue here is that Colloquy is trying to access the DOM from the didFinishLoadForFrame: delegate call. In cases where there are many WebViews loading at once, the HTML parser and tokenizer doesn't finish making the DOM until after didFinishLoadForFrame: is called. This design has always been the case in WebKit. It is never guaranteed that the DOM will be ready when didFinishLoadForFrame is called. Colloquy does a workaround and will release an update sometime. We should rethink this API and decide what didFinishLoadForFrame really means and make that clear in the API docs also. The attached patch almost fixes this completely but it broke the fast/dom/Document/document-reopen.html layout test. This test never closes the document, so with this patch didFinishLoadForFrame never fires. We need to rework the loader to fire the didFinishLoadForFrame when the main resource and sub-resource loads finish and the parser is done. But this test re-opens the document and makes the page seem like it never finishes. The explicit document.open with no document.close should not affect this delegate call.
Timothy Hatcher
Comment 5 2007-07-17 16:03:16 PDT
Timothy Hatcher
Comment 6 2007-07-17 16:03:48 PDT
Created attachment 15556 [details] Almost working patch
Note You need to log in before you can comment on or make changes to this bug.