I noticed this issue due to the fix for bug #149311. Later down in WebSocket::connect() there is a call to document.frame()->loader().mixedContentChecker(). I don't see why that doesn't crash now, since it occurs if (is<Document>(*scriptExecutionContext()), the same condition as the null dereference of frame up above, which was problematic in bug #149311. That was "safe" when I added it because document.frame() was assumed to be nonnull up above, but clearly that was wrong and is now no longer the case. I guess if it's not crashing (is it returning early on an error path?), then it might not be a problem, but it looks dangerous in light of this change... do we need to add a check to make sure frame is not null there? If so, do we need to rethink how to gain access to the mixed content checker, or is the content in a detached frame not going to be loaded? We need to be careful not to accidentally allow loading insecure content here.
It looks like this has been refactored and frame is null-checked now.