Bug 15019 – REGRESSION (r25124-r25140): New posts and hot topics won't show

• Component: New Bugs
• Status: RESOLVED FIXED

[Jiawei Ye]

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.

[David Kilzer (:ddkilzer)]

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).

[David Kilzer (:ddkilzer)]

Per autospade, this regressed between r25124 (works) and r25140 (fails).

[David Kilzer (:ddkilzer)]

<rdar://problem/5422410>

[Alice Liu]

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.  

[Alice Liu]

... 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.

[Alice Liu]

caused by r25128 which contains both loader and rendering changes

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.

[Alice Liu]

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.  

(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.

[Anders Carlsson]

Committed revision 25194.