Bug 15574 - Web Inspector doesn't work with the new Database feature
Summary: Web Inspector doesn't work with the new Database feature
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Web Inspector (Deprecated) (show other bugs)
Version: 523.x (Safari 3)
Hardware: All All
: P4 Normal
Assignee: Nobody
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2007-10-20 03:33 PDT by Ralf D.
Modified: 2008-04-04 14:42 PDT (History)
5 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ralf D. 2007-10-20 03:33:47 PDT
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
Comment 1 Brady Eidson 2007-10-20 09:35:52 PDT
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
Comment 2 Timothy Hatcher 2007-10-20 09:52:41 PDT
This isn't always happening, sometimes it works.
Comment 3 Mark Rowe (bdash) 2007-10-20 09:57:47 PDT
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.
Comment 4 Mark Rowe (bdash) 2007-10-20 10:43:02 PDT
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!
Comment 5 Timothy Hatcher 2007-10-20 11:19:41 PDT
We can always open a new database instance that only the inspector owns.
Comment 6 Mark Rowe (bdash) 2007-10-20 14:12:25 PDT
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.
Comment 7 Darin Adler 2007-10-20 19:57:16 PDT
Why is Mark's change considered a workaround, and not a fix?
Comment 8 Timothy Hatcher 2007-10-20 21:37:48 PDT
We think it is working around XSS security, similar to the hole Sam fixed for addEventListener <rdar://problem/5426142>.
Comment 9 Timothy Hatcher 2007-10-20 21:40:25 PDT
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());
     }

Comment 10 Ian 'Hixie' Hickson 2007-10-23 01:16:30 PDT
The callback should run with the security context of the script that created the callback, no?
Comment 11 Adam Roben (:aroben) 2008-01-29 11:16:08 PST
<rdar://problem/5712937>
Comment 12 Timothy Hatcher 2008-04-04 14:42:06 PDT
I tried removing the workaround, and all seems to work.