Due to <http://trac.webkit.org/changeset/91206>, 'Lord of Ultima' does not load in WebKit nightly builds. You can successfully log in, but when launching the game it gets stuck at a loading progress bar. Note that there is a separate bug about the game not properly drawing its background (tracked by <https://bugs.webkit.org/show_bug.cgi?id=64378>), but this bug seems to be unrelated.
<rdar://problem/9802719>
What is "Lord of Ultima"? Are you testing in WK2 or WK1?
(In reply to comment #2) > What is "Lord of Ultima"? See the URL field. > Are you testing in WK2 or WK1? Like I said, this reproduces in a WebKit nightly build, which uses WebKit1.
I realize I might have been overly vague with my last comment. I should be clear that I can reproduce this bug in both WebKit1 and a WebKit2.
Stacktrace: #2 0x00000001014146a8 in WebKit::NetscapePluginHostProxy::processRequests (this=0x11a874ee0) at /usr/local/home/jamesr/WebKit/Source/WebKit/mac/Plugins/Hosted/NetscapePluginHostProxy.mm:303 #3 0x000000010141ed93 in WebKit::NetscapePluginInstanceProxy::processRequestsAndWaitForReply (this=0x11a887c70, requestID=6) at /usr/local/home/jamesr/WebKit/Source/WebKit/mac/Plugins/Hosted/NetscapePluginInstanceProxy.mm:804 #4 0x000000010143cae3 in WebKit::NetscapePluginInstanceProxy::waitForReply<WebKit::NetscapePluginInstanceProxy::BooleanAndDataReply> (this=0x11a887c70, requestID=6) at NetscapePluginInstanceProxy.h:261 #5 0x0000000101421192 in WebKit::NetscapePluginInstanceProxy::snapshot (this=0x11a887c70, context=0x118e2e270, width=6, height=6) at /usr/local/home/jamesr/WebKit/Source/WebKit/mac/Plugins/Hosted/NetscapePluginInstanceProxy.mm:521 #6 0x00000001014a4779 in -[WebHostedNetscapePluginView drawRect:] (self=0x11a8edfd0, _cmd=0x7fff83d0e560, rect={origin = {x = 0, y = 0}, size = {width = 6, height = 6}}) at /usr/local/home/jamesr/WebKit/Source/WebKit/mac/Plugins/Hosted/WebHostedNetscapePluginView.mm:444 #7 0x0000000101451895 in -[WebBaseNetscapePluginView cacheSnapshot] (self=0x11a8edfd0, _cmd=0x7fff80ddb726) at /usr/local/home/jamesr/WebKit/Source/WebKit/mac/Plugins/WebBaseNetscapePluginView.mm:587 #8 0x000000010148f4dd in NetscapePluginWidget::notifyWidget (this=0x11a377d40, notification=WebCore::WillPaintFlattened) at /usr/local/home/jamesr/WebKit/Source/WebKit/mac/WebCoreSupport/WebFrameLoaderClient.mm:1670 #9 0x0000000103616db4 in WebCore::RenderWidget::notifyWidget (this=0x11a30b698, notification=WebCore::WillPaintFlattened) at /usr/local/home/jamesr/WebKit/Source/WebCore/rendering/RenderWidget.cpp:228 #10 0x000000010360d9b1 in WebCore::RenderView::notifyWidgets (this=0x11a83cbe8, notification=WebCore::WillPaintFlattened) at /usr/local/home/jamesr/WebKit/Source/WebCore/rendering/RenderView.cpp:647 #11 0x0000000102e216c0 in WebCore::FrameView::notifyWidgetsInAllFrames (this=0x11a39c400, notification=WebCore::WillPaintFlattened) at /usr/local/home/jamesr/WebKit/Source/WebCore/page/FrameView.cpp:2870 #12 0x0000000102e2706c in WebCore::FrameView::paintContents (this=0x11a39c400, p=0x7fff5fbfd870, rect=@0x7fff5fbfd910) at /usr/local/home/jamesr/WebKit/Source/WebCore/page/FrameView.cpp:2500 #13 0x000000010147f294 in -[WebFrame(WebInternal) _drawRect:contentsOnly:] (self=0x109929ce0, _cmd=0x7fff80dd58b3, rect={origin = {x = 0, y = 0}, size = {width = 1360, height = 1078}}, contentsOnly=1 '\001') at /usr/local/home/jamesr/WebKit/Source/WebKit/mac/WebView/WebFrame.mm:582 #14 0x00000001014baa78 in -[WebHTMLView drawSingleRect:] (self=0x11a87b1d0, _cmd=0x7fff80dff84c, rect={origin = {x = 0, y = 0}, size = {width = 1360, height = 1078}}) at /usr/local/home/jamesr/WebKit/Source/WebKit/mac/WebView/WebHTMLView.mm:3221 #15 0x00000001014ba6b6 in -[WebHTMLView drawRect:] (self=0x11a87b1d0, _cmd=0x7fff83d0e560, rect={origin = {x = 0, y = 0}, size = {width = 1360, height = 1078}}) at /usr/local/home/jamesr/WebKit/Source/WebKit/mac/WebView/WebHTMLView.mm:3265 #16 0x00007fff83757f5d in -[NSView(NSInternal) _recursive:displayRectIgnoringOpacity:inContext:topView:] () #17 0x00000001014b1c1f in -[WebHTMLView(WebPrivate) _recursive:displayRectIgnoringOpacity:inContext:topView:] (self=0x11a87b1d0, _cmd=0x7fff83df6676, recurse=1 '\001', displayRect={origin = {x = 0, y = 0}, size = {width = 1360, height = 1078}}, context=0x1199900f0, topView=1 '\001') at /usr/local/home/jamesr/WebKit/Source/WebKit/mac/WebView/WebHTMLView.mm:1388 #18 0x00007fff83757796 in -[NSView displayRectIgnoringOpacity:inContext:] () #19 0x00000001000468fc in ?? () #20 0x0000000100046616 in ?? () #21 0x000000010004631b in ?? () #22 0x000000010004615e in ?? () #23 0x0000000100045c06 in ?? () #24 0x0000000100045ac7 in ?? () #25 0x00007fff80f1fcb5 in __NSFireTimer () #26 0x0000000101a31be8 in __CFRunLoopRun () #27 0x0000000101a2fdbf in CFRunLoopRunSpecific () #28 0x00007fff848777ee in RunCurrentEventLoopInMode () #29 0x00007fff848775f3 in ReceiveNextEventCommon () #30 0x00007fff848774ac in BlockUntilNextEventMatchingListInMode () #31 0x00007fff83612eb2 in _DPSNextEvent () #32 0x00007fff83612801 in -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] () #33 0x0000000100015ffa in ?? () #34 0x00007fff835d868f in -[NSApplication run] () #35 0x00007fff835d13b0 in NSApplicationMain () #36 0x0000000100009f1c in ?? () so what's happening here is that WebKit has sent a mach message to the plugin process, but it never gets a response. I can't really debug usefully on the plugin side in WK1 since the plugin runner is closed-source. These issues are tricky to debug. The most likely culprit is that some subtle ordering constraint is being violated, confusing the plugin or causing initialization to fail. Is there a way to log all of the WebKit-side activity involved in plugin startup?
Does this happen if Safari is launched as 32-bit? 32-bit WebKit1 will load the plug-ins in-process which may make this slightly easier to debug.
I'm wondering if the fix in bug 64841 took care of this.
I tested the patch on bug 64841 locally and it did not seem to address this issue. Next I'll try debugging with 32 bit Safari as bdash suggested to see if that makes it clearer.
It looks like <http://trac.webkit.org/changeset/91383> fixed this for WebKit2 but not WebKit1.
I also noticed that this bug exists when running WebKit ToT against Safari 5's WebKitPluginHost (i.e. WebKit nightly builds on Snow Leopard), but it does *not* exist when running WebKit ToT against Safari 5.1's WebKitPluginHost. That indicates we've made some change on the plugin host side since shipping Safari 5 that tolerates your monotonic timer change. I think fixing WebKit so that it continues to work with WebKit nighties running in Safari 5.0.x would be nice, but it seems less important now (to me at least) given the information above.
Seems like it's all good now, then, for everyone except users who install nightly WebKits but don't update to Safari 5.1.
It would also be wrong for any other browser using WebKit1 (there are several ones like that). Is the underlying problem a real bug that would affect more than browsers, but every WebKit1-based application?
(In reply to comment #12) > It would also be wrong for any other browser using WebKit1 (there are several ones like that). Is the underlying problem a real bug that would affect more than browsers, but every WebKit1-based application? Would such applications use WebKit1 + the pre-5.1 WebKitPluginHost? From what we can tell, the bug is something to do with older versions of WebKitPluginHost.
Sounds good, thanks. I didn't (and don't) understand the nature of this bug, thus asking.