Bug 15019 - REGRESSION (r25124-r25140): New posts and hot topics won't show
Summary: REGRESSION (r25124-r25140): New posts and hot topics won't show
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: New Bugs (show other bugs)
Version: 523.x (Safari 3)
Hardware: Mac (Intel) OS X 10.4
: P1 Critical
Assignee: Nobody
URL: http://www.mobile01.com/
Keywords: InRadar, NeedsReduction, Regression
Depends on:
Blocks:
 
Reported: 2007-08-20 06:16 PDT by Jiawei Ye
Modified: 2007-08-22 17:28 PDT (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jiawei Ye 2007-08-20 06:16:51 PDT
Sometimes when accessing the site in URL, the middle box will show blank instead of lists of hot topics and new posts. Safari 3.0.3 Beta does not display such problem.
Comment 1 David Kilzer (:ddkilzer) 2007-08-20 07:30:02 PDT
Confirmed with a local debug build of WebKit r25149 with Safari 3 Public Beta v. 3.0.3 (522.12.1) on Mac OS X 10.4.10 (8R218).

Comment 2 David Kilzer (:ddkilzer) 2007-08-20 07:39:58 PDT
Per autospade, this regressed between r25124 (works) and r25140 (fails).

Comment 3 David Kilzer (:ddkilzer) 2007-08-20 07:44:47 PDT
<rdar://problem/5422410>
Comment 4 Alice Liu 2007-08-22 11:19:00 PDT
if i already have this page in my cache, the first visit to the page in a new window or tab will not exhibit the bug, but if i refresh, the bug will appear.  
Comment 5 Alice Liu 2007-08-22 11:22:00 PDT
... and also, if you are missing the content, then if you put your cursor in the address bar and press enter, then the missing content re-appears.
Comment 6 Alice Liu 2007-08-22 13:31:46 PDT
caused by r25128 which contains both loader and rendering changes
Comment 7 mitz 2007-08-22 15:01:58 PDT
The problem seems to stem from the load event handler being dispatched during layout (and possibly too soon). The backtrace looks like <http://paste.lisp.org/display/46503>. The results can be much worse than this bug if the event handler changes the DOM.
Comment 8 Alice Liu 2007-08-22 15:58:00 PDT
I have a couple of comments:

- one time while loading mobile01.com, i crashed with this backtrace.  Even though i haven't been able to reproduce this crash, i thought i'd mention it since Mitz said that consequences of the handler being called during layout can be much worse. 

Thread 0 Crashed:
0   com.apple.WebCore             	0x016bbc24 +[DOMNode(WebCoreInternal) _wrapNode:] + 120 (DOM.mm:315)
1   com.apple.WebCore             	0x0193e97a +[DOMElement(WebCoreInternal) _wrapElement:] + 64 (DOMElement.mm:337)
2   com.apple.WebKit              	0x00359f92 WebFrameLoaderClient::createPlugin(WebCore::Element*, WebCore::KURL const&, WTF::Vector<WebCore::String, 0ul> const&, WTF::Vector<WebCore::String, 0ul> const&, WebCore::String const&, bool) + 308
3   com.apple.WebCore             	0x01a0c3ff WebCore::FrameLoader::loadPlugin(WebCore::RenderPart*, WebCore::KURL const&, WebCore::String const&, WTF::Vector<WebCore::String, 0ul> const&, WTF::Vector<WebCore::String, 0ul> const&, bool) + 429 (FrameLoader.cpp:1534)
4   com.apple.WebCore             	0x01a18352 WebCore::FrameLoader::requestObject(WebCore::RenderPart*, WebCore::String const&, WebCore::AtomicString const&, WebCore::String const&, WTF::Vector<WebCore::String, 0ul> const&, WTF::Vector<WebCore::String, 0ul> const&) + 426 (FrameLoader.cpp:1495)
5   com.apple.WebCore             	0x01880345 WebCore::RenderPartObject::updateWidget(bool) + 4065 (RenderPartObject.cpp:261)
6   com.apple.WebCore             	0x01880469 WebCore::RenderPartObject::layout() + 175 (RenderPartObject.cpp:278)

- If you comment out the early return that occurs about 5 lines up from the end of RenderPartObject::updateWidget(), then the mobile01.com bug goes away without re-introducing the bug that anders fixed with r25128.  
Comment 9 mitz 2007-08-22 16:29:57 PDT
(In reply to comment #8)
> I have a couple of comments:
> 
> - one time while loading mobile01.com, i crashed with this backtrace.

That crash seems to happen even before event dispatch so it might be a different problem.

> - If you comment out the early return that occurs about 5 lines up from the end
> of RenderPartObject::updateWidget(), then the mobile01.com bug goes away
> without re-introducing the bug that anders fixed with r25128.  

That's weird. Maybe the original bug involved <object> (the early return is in the <embed> branch; there's another one in the <object> branch). I'd expect the layout test from r25128 to fail without the early return.

I am pretty sure now that the checkCallImplicitClose() in FrameLoader::loadPlugin() needs to be removed. It can lead to the load event being dispatched before all images have finished loading.
Comment 10 Anders Carlsson 2007-08-22 17:28:12 PDT
Committed revision 25194.