Fix DevTools support of worklets

third_party/WebKit/Source/core/inspector/MainThreadDebugger.cpp

Index: third_party/WebKit/Source/core/inspector/MainThreadDebugger.cpp
diff --git a/third_party/WebKit/Source/core/inspector/MainThreadDebugger.cpp b/third_party/WebKit/Source/core/inspector/MainThreadDebugger.cpp
index c5231f3773fa64d14dffbbc95a5f4dbf01dd43f0..4fc292458970463a6949d23db79e9323341b9be0 100644
--- a/third_party/WebKit/Source/core/inspector/MainThreadDebugger.cpp
+++ b/third_party/WebKit/Source/core/inspector/MainThreadDebugger.cpp
@@ -189,16 +189,7 @@ void MainThreadDebugger::unmuteConsole()
 
 bool MainThreadDebugger::callingContextCanAccessContext(v8::Local<v8::Context> calling, v8::Local<v8::Context> target)

[haraken, 2016/06/29 00:23:35]

Not directly related to the CL, but is there any reason you have to use a
calling context here? We're deprecating a calling context (because it's broken
in many ways) and replacing it with a current context. Would it be possible to
use a current context instead?

[Gleb Lanbin, 2016/06/29 17:07:13]

please see the reply from dgozman@ above in this thread

 {
-    ExecutionContext* executionContext = toExecutionContext(target);
-    ASSERT(executionContext);
-
-    if (executionContext->isMainThreadWorkletGlobalScope()) {
-        MainThreadWorkletGlobalScope* globalScope = toMainThreadWorkletGlobalScope(executionContext);
-        return globalScope && BindingSecurity::shouldAllowAccessTo(m_isolate, toLocalDOMWindow(toDOMWindow(calling)), globalScope, DoNotReportSecurityError);
-    }
-
-    DOMWindow* window = toDOMWindow(target);
-    return window && BindingSecurity::shouldAllowAccessTo(m_isolate, toLocalDOMWindow(toDOMWindow(calling)), window, DoNotReportSecurityError);
+    return BindingSecurity::shouldAllowAccessTo(m_isolate, calling, target, DoNotReportSecurityError);
 }
 
 int MainThreadDebugger::ensureDefaultContextInGroup(int contextGroupId)