15574 2007-10-20 03:33:47 -0700 Web Inspector doesn't work with the new Database feature 2008-04-04 14:42:06 -0700 1 1 1 Unclassified WebKit Web Inspector (Deprecated) 523.x (Safari 3) All All RESOLVED FIXED InRadar P4 Normal --- 1 nsstring webkit-unassigned beidson ian mrowe sam timothy oldest_to_newest 58900 0 nsstring 2007-10-20 03:33:47 -0700 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 58910 1 beidson 2007-10-20 09:35:52 -0700 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 58911 2 timothy 2007-10-20 09:52:41 -0700 This isn't always happening, sometimes it works. 58912 3 mrowe 2007-10-20 09:57:47 -0700 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. 58919 4 mrowe 2007-10-20 10:43:02 -0700 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! 58920 5 timothy 2007-10-20 11:19:41 -0700 We can always open a new database instance that only the inspector owns. 58927 6 mrowe 2007-10-20 14:12:25 -0700 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. 58965 7 darin 2007-10-20 19:57:16 -0700 Why is Mark's change considered a workaround, and not a fix? 58973 8 timothy 2007-10-20 21:37:48 -0700 We think it is working around XSS security, similar to the hole Sam fixed for addEventListener <rdar://problem/5426142>. 58974 9 timothy 2007-10-20 21:40:25 -0700 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()); } 59240 10 ian 2007-10-23 01:16:30 -0700 The callback should run with the security context of the script that created the callback, no? 68677 11 aroben 2008-01-29 11:16:08 -0800 <rdar://problem/5712937> 76340 12 timothy 2008-04-04 14:42:06 -0700 I tried removing the workaround, and all seems to work.