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 7bf038fca093d0cd472f907cf310d912814f9ca1..3e4ffb1c82e6d6d51033a07b9fcbdf3d7f26cfab 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"
@@ -72,6 +75,9 @@ IDBRequest::IDBRequest(ScriptState* scriptState, IDBAny* source, IDBTransaction*
     , m_resultDirty(true)
 {
     ScriptWrappable::init(this);
+
+    if (scriptState->isolate()->InContext())
+        m_creationStackTrace = createScriptCallStack(ScriptCallStack::maxCallStackSizeToCapture, true);

[Mike West, 2014/06/13 09:27:52]

I'm a little worried about the performance impact of generating a stacktrace
every time we create a request. Do we have any IDB perf tests? If so, watch them
closely after landing this.

If not, we'll never notice anyway, so no worries. ;)

[jsbell, 2014/06/13 16:58:41]

We do have perf tests and I'm worried. 

Since it's not urgent I'll wait for a quiet time to land this, when no other IDB
changes or e.g. oilpan/v8 churn is planned.

 }
 
 IDBRequest::~IDBRequest()
@@ -493,6 +499,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?

[Mike West, 2014/06/13 09:27:52]

If you set this to "ShareableCrossOrigin", then `onerror` will always include
the stack and error message, regardless of the script that generated them. This
generally happens only when you add a `crossorigin` attribute to a `<script>`
tag, and it is delivered with proper CORS headers.

If you set it to "NotSharableCrossOrigin", then the details will only be
available if `frame.sourceURL()` (which you pass in below) is accessible from
`executionContext()`. That seems correct to me (it's also what we do in
Workers).

[jsbell, 2014/06/13 16:58:40]

Thanks for the explanation/confirmation!

+        const AccessControlStatus corsStatus = NotSharableCrossOrigin;
+
+        RefPtr<ErrorEvent> errorEvent;
+        if (executionContext()->shouldSanitizeScriptError(frame.sourceURL(), corsStatus)) {
+            errorEvent = ErrorEvent::createSanitizedError(&m_scriptState->world());
+        } else {
+            // FIXME: Firefox just uses error's name. Should we include the message?

[Mike West, 2014/06/13 09:27:52]

We have better messages than Firefox. We should use them.

[jsbell, 2014/06/13 16:58:41]

I thought you'd say that. :)

+            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;
 }