I get this Javascript error on the provided example site (http://webkit.org/misc/DatabaseExample.html) ----------- Undefined Value /Applications/WebKit.app/Contents/Resources/WebCore.framework/Versions/A/Resources/inspector/DatabasePanel.js line 429 ----------- See here: http://img98.imageshack.us/img98/2283/errorpu7.png
Something bogus is happening in the callback from this.database.database.executeSql(query, [], function(result) { panel.browseQueryFinished(result) }); in _tableForResult, it's almost like there's no global (window) object. window.document is null, and I tried to place a debugging alert() and it also failed due to undefined. o_O
This isn't always happening, sometimes it works.
It'll work against file:/// URLs. By the looks of things, the callback Brady mentions is running in the security context of the page in the web browser but with the global object of the inspector. This means it is unable to access any properties of the window object without triggering a yummy "Unsafe JavaScript attempt to access frame" error.
To clarify a little: * this.database.database is the Database instance from within the frame at http://webkit.org/misc/DatabaseExample.html. * Calling executeSql on this object will result in the callback being executed within that frame's interpreter and thus that frame's security context. * The callback function was created within the inspector's interpreter, and thus has the inspector's window object in its scope chain. * When the callback function attempts to access the window object, this is a security violation (accessing an object in the inspector's security domain from within the websites interpreter). I can't think of any simple solution to this. Hopefully someone more clueful can!
We can always open a new database instance that only the inspector owns.
I landed a workaround for this issue in r26830 (http://trac.webkit.org/projects/webkit/changeset/26830). The behaviour being worked around definitely feels incorrect in some respect, so I think this deserves further investigation to determine what the correct fix is.
Why is Mark's change considered a workaround, and not a fix?
We think it is working around XSS security, similar to the hole Sam fixed for addEventListener <rdar://problem/5426142>.
A real fix would be: Index: WebCore/bindings/js/JSDatabaseCustom.cpp =================================================================== --- WebCore/bindings/js/JSDatabaseCustom.cpp (revision 26802) +++ WebCore/bindings/js/JSDatabaseCustom.cpp (working copy) @@ -99,7 +99,7 @@ return jsUndefined(); } - if (Frame* frame = m_impl->document()->frame()) { + if (Frame* frame = Window::retrieveActive(exec)->impl()->frame()) { RefPtr<VersionChangeCallback> changeCallback(new JSCustomVersionChangeCallback(callback, frame)); m_impl->changeVersion(oldVersion, newVersion, changeCallback.release()); }
The callback should run with the security context of the script that created the callback, no?
<rdar://problem/5712937>
I tried removing the workaround, and all seems to work.