2011-09-24 1:02:14.283 PM [0x0-0x1ab1ab].com.apple.Safari: Receive an invalid message from the web process with message ID 31e002d
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x00000000bbadbeef
0x0000000102afdcea in WebKit::WebPageProxy::decidePolicyForNavigationAction (this=0x109804600, frameID=3, opaqueNavigationType=5, opaqueModifiers=0, opaqueMouseButton=6357106, request=@0x7fff5fbfd9d0, listenerID=2, arguments=0x1129320e0, receivedPolicyAction=@0x7fff5fbfd998, policyAction=@0x7fff5fbfd9a0, downloadID=@0x7fff5fbfd9a8) at /Volumes/Data/Users/mrowe/Documents/Work/WebKit-git/OpenSource/Source/WebKit2/UIProcess/WebPageProxy.cpp:1795
(gdb) po request.url().createCFURL()
The way we solve this in Chromium is to use a URL scheme other that "file" for the web inspector. For example, we used the scheme "inspector" at some point. Now, I think we use "chrome", which is the scheme we use for a bunch of browser-provided HTML UI.
I’m pretty sure this is just an oversight in r95747 and that the code path that shows the inspector simply isn’t making the necessary call so that the MESSAGE_CHECK_URL call knows that the UI process initiated the load of the inspector.
Yep, that's another approach to solving this problem.
As Mark says, WebInspectorProxy::createInspectorPage() should add WebCore resources folder to WebProcessProxy::m_localPathsWithAssumedReadAccess. I'll work on this ASAP (which might be Monday).
Created attachment 108704 [details]
Comment on attachment 108704 [details]
Clearing flags on attachment: 108704
Committed r96014: <http://trac.webkit.org/changeset/96014>
All reviewed patches have been landed. Closing bug.
Qt-WK2 buildfix landed in http://trac.webkit.org/changeset/96067