Fire window.onerror for uncaught IndexedDB errors

Source/modules/indexeddb/IDBRequest.cpp

Index: Source/modules/indexeddb/IDBRequest.cpp
diff --git a/Source/modules/indexeddb/IDBRequest.cpp b/Source/modules/indexeddb/IDBRequest.cpp
index 8bab481acd04588ae746702afc9acc8d6e0995c7..cb11e6d61edd798c1ea2e0edbd9eb0845069e059 100644
--- a/Source/modules/indexeddb/IDBRequest.cpp
+++ b/Source/modules/indexeddb/IDBRequest.cpp
@@ -32,8 +32,11 @@
 #include "bindings/v8/ExceptionState.h"
 #include "bindings/v8/ExceptionStatePlaceholder.h"
 #include "bindings/v8/IDBBindingUtilities.h"
+#include "bindings/v8/ScriptCallStackFactory.h"
 #include "core/dom/ExecutionContext.h"
 #include "core/events/EventQueue.h"
+#include "core/inspector/ScriptCallFrame.h"
+#include "core/inspector/ScriptCallStack.h"
 #include "modules/indexeddb/IDBCursorWithValue.h"
 #include "modules/indexeddb/IDBDatabase.h"
 #include "modules/indexeddb/IDBEventDispatcher.h"
@@ -71,6 +74,9 @@ IDBRequest::IDBRequest(ExecutionContext* context, PassRefPtr<IDBAny> source, IDB
     , m_resultDirty(true)
 {
     ScriptWrappable::init(this);
+
+    if (toIsolate(context)->InContext())
+        m_creationStackTrace = createScriptCallStack(ScriptCallStack::maxCallStackSizeToCapture, true);

[haraken, 2014/04/21 02:36:13]

Is it safe to limit the number of captured stack trace to
maxCallStackSizeToCapture? If there are a lot of stacks and we capture only a
part of the stacks, then we will end up firing window.error on a wrong frame
(which might be malicious).

[jsbell, 2014/04/21 16:28:38]

Is it possible to capture more? Maybe I'm misunderstanding that enum's purpose.
Is the content of the stack (other than the current frame) used for security
decisions? 

 }
 
 IDBRequest::~IDBRequest()
@@ -471,6 +477,23 @@ bool IDBRequest::dispatchEvent(PassRefPtrWillBeRawPtr<Event> event)
     if (m_readyState == DONE && event->type() != EventTypeNames::upgradeneeded)
         m_hasPendingActivity = false;
 
+    if (!m_preventPropagation && dontPreventDefault && event->type() == EventTypeNames::error && m_creationStackTrace && m_creationStackTrace->size()) {
+        const ScriptCallFrame& frame = m_creationStackTrace->at(0);
+
+        // FIXME: SharableCrossOrigin or NotSharableCrossOrigin?
+        const AccessControlStatus corsStatus = NotSharableCrossOrigin;
+
+        RefPtr<ErrorEvent> errorEvent;
+        if (executionContext()->shouldSanitizeScriptError(frame.sourceURL(), corsStatus)) {

[haraken, 2014/04/21 02:36:13]

Is it OK to use the executionContext of this IDBRequest object? Or should we use
an executionContext of the |frame|?

[jsbell, 2014/04/21 16:28:38]

Great question. Anyone?

+            errorEvent = ErrorEvent::createSanitizedError(&m_scriptState->world());
+        } else {
+            // FIXME: Firefox just uses error's name. Should we include the message?

[jsbell, 2014/04/21 16:28:38]

And for the record: I plan to keep the message, especially as our messages are
pretty informative. I don't see a big compat concern here and we can hammer it
out in the IDBv2 spec.

+            String message = m_error->name() + ": " + m_error->message();
+            errorEvent = ErrorEvent::create(message, frame.sourceURL(), frame.lineNumber(), frame.columnNumber(), &m_scriptState->world());
+        }
+        executionContext()->reportException(errorEvent, m_creationStackTrace, corsStatus);
+    }
+
     return dontPreventDefault;
 }