This bug was filed from the Socorro interface and is report bp-8c8dfc29-21e2-4a57-a4d4-9f7c30180813. ============================================================= Top 10 frames of crashing thread: 0 XUL void NS_QueryNotificationCallbacks<nsIChannel> netwerk/base/nsNetUtil.h:624 1 XUL ThirdPartyUtil::GetTopWindowForChannel netwerk/base/nsNetUtil.h:647 2 XUL nsContentUtils::StorageDisabledByAntiTracking dom/base/nsContentUtils.cpp:8937 3 XUL mozilla::image::ImageCacheKey::GetSpecialCaseDocumentToken image/ImageCacheKey.cpp:155 4 XUL mozilla::image::ImageCacheKey::ImageCacheKey image/ImageCacheKey.cpp:48 5 XUL imgLoader::LoadImage image/imgLoader.cpp:2349 6 XUL nsContentUtils::LoadImage dom/base/nsContentUtils.cpp:3633 7 XUL nsImageLoadingContent::LoadImage dom/base/nsImageLoadingContent.cpp:1040 8 XUL nsImageLoadingContent::LoadImage dom/base/nsImageLoadingContent.cpp:916 9 XUL mozilla::dom::HTMLImageElement::AfterMaybeChangeAttr dom/html/HTMLImageElement.cpp:470 =============================================================

Comment on attachment 8999726 [details] [diff] [review] Handle null arguments in nsContentUtils::StorageDisabledByAntiTracking correctly GetOuterWindow may return null, please null check. (I wouldn't be surprised this method being called after unlink) Would be nice to document in .h that either aWindow or aChannel can be null.

Pushed by eakhgari@mozilla.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/f93a51060a07 Handle null arguments in nsContentUtils::StorageDisabledByAntiTracking correctly; r=smaug