WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED WORKSFORME
64825
REGRESSION (
r91206
): 'Lord of Ultima' does not load
https://bugs.webkit.org/show_bug.cgi?id=64825
Summary
REGRESSION (r91206): 'Lord of Ultima' does not load
Andy Estes
Reported
2011-07-19 14:09:28 PDT
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.
Attachments
Add attachment
proposed patch, testcase, etc.
Andy Estes
Comment 1
2011-07-19 14:10:01 PDT
<
rdar://problem/9802719
>
James Robinson
Comment 2
2011-07-19 14:30:32 PDT
What is "Lord of Ultima"? Are you testing in WK2 or WK1?
Andy Estes
Comment 3
2011-07-19 14:32:52 PDT
(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.
Andy Estes
Comment 4
2011-07-19 14:42:54 PDT
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.
James Robinson
Comment 5
2011-07-19 18:16:01 PDT
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?
Mark Rowe (bdash)
Comment 6
2011-07-20 03:52:44 PDT
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.
Alexey Proskuryakov
Comment 7
2011-07-20 13:26:36 PDT
I'm wondering if the fix in
bug 64841
took care of this.
James Robinson
Comment 8
2011-07-20 13:42:01 PDT
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.
Andy Estes
Comment 9
2011-07-20 16:53:29 PDT
It looks like <
http://trac.webkit.org/changeset/91383
> fixed this for WebKit2 but not WebKit1.
Andy Estes
Comment 10
2011-07-20 17:18:35 PDT
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.
James Robinson
Comment 11
2011-07-21 11:53:34 PDT
Seems like it's all good now, then, for everyone except users who install nightly WebKits but don't update to Safari 5.1.
Alexey Proskuryakov
Comment 12
2011-09-02 15:48:12 PDT
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?
James Robinson
Comment 13
2011-09-02 15:51:38 PDT
(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.
Alexey Proskuryakov
Comment 14
2011-09-02 17:10:53 PDT
Sounds good, thanks. I didn't (and don't) understand the nature of this bug, thus asking.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug