I've been getting these traps all day, almost immediately, with r45357. Scenario is debugging the web inspector. Bring up a web app to debug in WebKit, enter Web Inspector. Select file from file list, set a breakpoint. Now get a context menu somewhere in the inspector window and click "inspect element", which will launch a new inspector, this time with the Web Inspector code itself. Set a breakpoint somewhere in that inspector. Now switch back to the original inspector, select a different source file - kaboom. Inspecting the inspector is something I've done often over the last two months or so, generally there isn't any problem doing this. Will attach a stack trace.
Created attachment 32077 [details] stack trace
Same bug / stack trace occurring in nightly r45463
Still occurring on nightly r45585. Brought up XCode to see if anything was obviously wrong. But I'm lost, wandering in a sea of C++ wonderfulness. :-) Here's where things appear to be breaking down. On the stack, I'm in JSDOMWindowCustom.h, in JSDOMWindowBase::allowAccessFromPrivate, which looks like this: ---- ALWAYS_INLINE bool JSDOMWindowBase::allowsAccessFromPrivate(const JSGlobalObject* other) const { const JSDOMWindow* originWindow = asJSDOMWindow(other); const JSDOMWindow* targetWindow = d()->shell->window(); if (originWindow == targetWindow) return true; const SecurityOrigin* originSecurityOrigin = originWindow->impl()->securityOrigin(); const SecurityOrigin* targetSecurityOrigin = targetWindow->impl()->securityOrigin(); return originSecurityOrigin->canAccess(targetSecurityOrigin); } ---- When the return statement is processed, originSecurityOrigin is null. Can't really decipher the origin/targetWindows to tell what's going on. An obvious tidbit after perusing the source is that ScriptFunctionCall on the stack at 10 appears to be calling a function "inspectedWindowCleared".
As of a nightly build this week, I can now sucessfully use Web Inspector on itself, which was the primary symptom for this bug. Feel free to close/resolve.