Open Bug 1503787 Opened 10 months ago Updated 10 days ago

Crash in mozilla::dom::ClientSource::WindowExecutionReady


(Core :: Privacy: Anti-Tracking, defect, P2, critical)

65 Branch
Windows 10



Tracking Status
firefox64 --- wontfix
firefox65 --- wontfix
firefox66 --- wontfix
firefox67 --- wontfix
firefox68 --- wontfix
firefox69 --- affected
firefox70 --- affected


(Reporter: baku, Assigned: baku)



(Keywords: crash, regression, Whiteboard: [privacy65][anti-tracking])

Crash Data

+++ This bug was initially created as a clone of Bug #1499995 +++

We still have some crash reports for mozilla::dom::ClientSource::WindowExecutionReady's assertions.
baku, are there any next steps we can take here?
Flags: needinfo?(amarchesini)
Assignee: nobody → amarchesini
User report of repeated crashes on feedly:
it appears to be semi-repeatable

I did see quite a few feedly crashes
jesup, have you been able to reproduce this crash somehow? Because I've tried any possible feed with feedly, but nothing.
I also suspect it's geolocation problem: I could receive different adverts from somebody else from another country.
Flags: needinfo?(amarchesini) → needinfo?(rjesup)
I have not tried; I don't use feedly (and barely touch reddit).  I was just investigating the crash reports
Flags: needinfo?(rjesup)
diagnostic asserts don't fire in late beta or release, wontfixing for 64.
See Also: → 1508044
Andrea, Ehsan said you might be interested in bug 1508044 comment 12 where I was able (with the patch in that bug) reproduce 

Assertion failure: spec.LowerCaseEqualsLiteral("about:blank") || StringBeginsWith(spec, static_cast<const nsLiteralCString&>(nsLiteralCString("" "blob:"))) || nsContentUtils::StorageAllowedForWindow(aInnerWindow) == nsContentUtils::StorageAccess::eAllow>

See Also: 1508044
Priority: -- → P1
Version: Trunk → 65 Branch
Target Milestone: --- → Future

This has a Target Milestone and is set to P1 so let's leave it off the 66 affected radar.

Component: DOM: Content Processes → Privacy: Anti-Tracking
Whiteboard: [privacy65] → [privacy65][anti-tracking]
Priority: P1 → P2

(I was wrong; the crash widget thing here seems to not match Socorro) There are quite a few patches across all channels, many at the same address. baku, can you take another look here?

Flags: needinfo?(amarchesini)

Baku, any news on this bug?

No crashes since beta 10, so wontfix for 67.

Flags: needinfo?(amarchesini)

Only one crash since 68 beta 9, so wontfix for 68

Adding 70 as affected. This is visible in 69 and one comment says "Still 100% tab crash on in RSS article with YouTube video in it. "

(In reply to Marcia Knous [:marcia - needinfo? me] from comment #13)

Adding 70 as affected. This is visible in 69 and one comment says "Still 100% tab crash on in RSS article with YouTube video in it. "

It was me, I have last nightly and it still 100% crash on in RSS article with YouTube video in it 🙂
Steps to reproduce:

  1. Open and sign in or create new account.
  2. Subscribe to feed with many video articles, for example
  3. Open article with embedded video in this feed.
  4. Gah. Your tab just crashed.

I got this crash (bp-051f94bd-6c2c-47c6-b6fb-8af6e0190809) on Youtube had this service worker from about:serviceworkers:


Script Spec:
Current Worker URL:
Active Cache Name: {ea8bd166-b827-4207-a351-8078d59a6524}
Waiting Cache Name: {$name}
Push Endpoint: null

(In reply to :Ehsan Akhgari from comment #15)

I got this crash (bp-051f94bd-6c2c-47c6-b6fb-8af6e0190809) on

Reproduced the crash on the same page again: bp-042cf8ba-1858-4fa7-b732-e23bc0190812

STR using the latest Nightly:

  1. Set to 3.
  2. Visit, and about:serviceworkers. Ensure that the YouTube service worker is installed.
  3. Make sure you only have one tab open. In that tab, navigate to
  4. Quit Nightly.
  5. Restart Firefox. At this point the session is restored, and the inexpensive-daisy page crashes while restoring with this signature (see comment 15 and 16).
Has STR: --- → yes
You need to log in before you can comment on or make changes to this bug.