Bug 14171 - DOM not always available in didFinishLoadForFrame if multiple WebViews are busy loading (Colloquy doesn't display chat messages)
Summary: DOM not always available in didFinishLoadForFrame if multiple WebViews are bu...
Status: ASSIGNED
Alias: None
Product: WebKit
Classification: Unclassified
Component: New Bugs (show other bugs)
Version: 523.x (Safari 3)
Hardware: Macintosh OS X 10.4
: P2 Normal
Assignee: Nobody
URL: http://colloquy.info/project/ticket/576
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2007-06-15 09:33 PDT by Alexander Kempgen
Modified: 2016-09-20 09:51 PDT (History)
8 users (show)

See Also:


Attachments
Almost working patch (516 bytes, patch)
2007-07-17 16:03 PDT, Timothy Hatcher
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Alexander Kempgen 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.
Comment 1 Brady Eidson 2007-06-16 09:22:22 PDT
a workaround, in the meantime, is to type "/reload style" in one of these blank webviews.
Comment 2 Mark Rowe (bdash) 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?
Comment 3 Timothy Hatcher 2007-07-17 11:23:17 PDT
I am working on the WebKit issue.
Comment 4 Timothy Hatcher 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.
Comment 5 Timothy Hatcher 2007-07-17 16:03:16 PDT
<rdar://problem/5036833>
Comment 6 Timothy Hatcher 2007-07-17 16:03:48 PDT
Created attachment 15556 [details]
Almost working patch