Summary: | ASSERT in WebDocumentLoaderMac::decreaseLoadCount() un-discarding Gmail message | ||||||
---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Brady Eidson <beidson> | ||||
Component: | Page Loading | Assignee: | Nobody <webkit-unassigned> | ||||
Status: | RESOLVED FIXED | ||||||
Severity: | Major | CC: | mbritto, sroret | ||||
Priority: | P1 | Keywords: | InRadar, Regression | ||||
Version: | 523.x (Safari 3) | ||||||
Hardware: | Mac (Intel) | ||||||
OS: | OS X 10.4 | ||||||
URL: | http://gmail.com | ||||||
Attachments: |
|
Description
Brady Eidson
2007-04-16 11:20:46 PDT
<rdar://problem/5133420> also, this seems almost certainly related to http://bugs.webkit.org/show_bug.cgi?id=13360 (In reply to comment #1) > <rdar://problem/5133420> > > also, this seems almost certainly related to > http://bugs.webkit.org/show_bug.cgi?id=13360 > The bug 13360 is fixed now but this one still occurs. I think the problem is in the HTMLFrameElementBase::willRemove() call because : - if we "undo discard" on Gmail with a new message contentFrame() returns 0 - if we "undo discard" on Gmail with a reply message (the one which leads to the crash) the contentFrame() returns something so we get in the "if" condition and then we crash. I've also tried to comment everything inside the if and I can no longer reproduce the crash ; obviously that is not the solution but it shows it's related to this fonction and maybe we need to modify the condition by adding something to handle this particulary case. Created attachment 15116 [details]
proposed patch
If a provisionnal frame loader never gets committed, this patch is dropping it if it's still alive when trying to detach the frame.
The bug is no longer reproductible and no test cases are affected by this.
Though I can't produce a layout test because I don't know why this provisionnal frame loader never gets committed.
Comment on attachment 15116 [details] proposed patch It should be impossible for the provisional document loader and the regular document loader to ever be the same: > + if ((m_provisionalDocumentLoader && m_documentLoader) && (m_provisionalDocumentLoader != m_documentLoader)) { Also, is the bug reproducible now or not? If the bug no longer happens, I'm not sure we should make a change. If it does, then it needs a test case. r- until these comments are addressed. When I said the bug was no longer reproductible, I meant with this patch. If I remove the patch, I can reproduce the assertion error, so the bug stills exists. My main problem with this bug is the fact that I don't know why this frame loader never gets commited. This patch fixes the bug, but I think I can find out a more effective solution if I understand why it's happening. |