Bug 14171

Summary:

DOM not always available in didFinishLoadForFrame if multiple WebViews are busy loading (Colloquy doesn't display chat messages)

Product:

WebKit

Reporter:

Alexander Kempgen <alex>

Component:

New Bugs

Assignee:

Nobody <webkit-unassigned>

Status:

ASSIGNED

Severity:

Normal

CC:

ap, cdumez, dev+webkit, edcrfv, ismail, jeff, pnasrat, tofu.linden

Priority:

Keywords:

InRadar

Version:

523.x (Safari 3)

Hardware:

Mac

OS:

OS X 10.4

URL:

http://colloquy.info/project/ticket/576

Attachments:

Description	Flags
Almost working patch	none

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	Details Formatted Diff Diff
View All Add attachment proposed patch, testcase, etc.

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

<rdar://problem/5036833>

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.