Bug 15574 – Web Inspector doesn't work with the new Database feature

• Component: Web Inspector (Deprecated)
• Status: RESOLVED FIXED

[Ralf D.]

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

[Brady Eidson]

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

[Timothy Hatcher]

This isn't always happening, sometimes it works.

[Mark Rowe (bdash)]

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.

[Mark Rowe (bdash)]

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!

[Timothy Hatcher]

We can always open a new database instance that only the inspector owns.

[Mark Rowe (bdash)]

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.

[Darin Adler]

Why is Mark's change considered a workaround, and not a fix?

[Timothy Hatcher]

We think it is working around XSS security, similar to the hole Sam fixed for addEventListener <rdar://problem/5426142>.

[Timothy Hatcher]

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());
     }

[Ian 'Hixie' Hickson]

The callback should run with the security context of the script that created the callback, no?

[Adam Roben (:aroben)]

<rdar://problem/5712937>

[Timothy Hatcher]

I tried removing the workaround, and all seems to work.