Andrei reported an issue with the crashes from bug 1721627 that happened locally but not on infra. When narrowing that down, I realized that I missed a JAR helper that gets called off-mainthread. Let's fix that. There's probably more brokenness lurking here. I think we've missed all async calls on jar: channels so far, which is likely to include missing images in various tests...

https://treeherder.mozilla.org/jobs?repo=try&revision=ad7fa2843b080376d707a6ed284ee8a0e867f88c

Luca or Mark, the trypush is flagging up this:

https://searchfox.org/mozilla-central/rev/f71cb98fc35da418d2cb9ce31a0416d532dc9d69/toolkit/mozapps/extensions/content/abuse-report-panel.js#755

returns undefined in some cases, which means we try to load chrome://mozapps/content/extensions/undefined, which of course doesn't exist.

(from local running, the JS stack looks like this:

0 update() ["chrome://mozapps/content/extensions/abuse-report-panel.js":618:22]
    this = [object HTMLElement]
1 setAbuseReport(abuseReport = "[object Object]") ["chrome://mozapps/content/extensions/abuse-report-panel.js":642:11]
    this = [object HTMLElement]
2 <TOP LEVEL> ["chrome://mozapps/content/extensions/abuse-report-panel.js":864:5]

Is it expected the iconURL or add-on can be missing here sometimes, and in that case, should we load nothing or a fallback image of some sort? Or are both the add-on and its iconURL guaranteed to exist, in which case, should we just fix the test so it passes a realistic object, and remove the && that copes with the addon being null/undefined?

Depends on D122162

Depends on D122163

Depends on D122164

Depends on D122165

Depends on D122166

Some addons may not include an icon (e.g. static themes addons) and so the abuse report panel should
fallback to the extensionGeneric.svg.

Falling back to the extensionGeneric.svg is also needed to prevent a diagnostic crash triggered by
loading non existing resources while running the abuse report mochitests.

(In reply to :Gijs (he/him) from comment #2)

Luca or Mark, the trypush is flagging up this:

https://searchfox.org/mozilla-central/rev/f71cb98fc35da418d2cb9ce31a0416d532dc9d69/toolkit/mozapps/extensions/content/abuse-report-panel.js#755

returns undefined in some cases, which means we try to load chrome://mozapps/content/extensions/undefined, which of course doesn't exist.

(from local running, the JS stack looks like this:

0 update() ["chrome://mozapps/content/extensions/abuse-report-panel.js":618:22]
    this = [object HTMLElement]
1 setAbuseReport(abuseReport = "[object Object]") ["chrome://mozapps/content/extensions/abuse-report-panel.js":642:11]
    this = [object HTMLElement]
2 <TOP LEVEL> ["chrome://mozapps/content/extensions/abuse-report-panel.js":864:5]

Is it expected the iconURL or add-on can be missing here sometimes, and in that case, should we load nothing or a fallback image of some sort? Or are both the add-on and its iconURL guaranteed to exist, in which case, should we just fix the test so it passes a realistic object, and remove the && that copes with the addon being null/undefined?

Hi Gijs,
I just looked into that and, even if the test is triggered by mock addons installed through the MockProvider (defined in head_abusereport.js, and I they do not have an iconURL), the scenario is actually legit: e.g. the static themes addons usually do not have an icon (in about:addons we do show a screenshot preview of the theme, but that doesn't fit in the current abuse report panel UI).

When the icon URL is missing, it would be reasonable to fallback to the extensionGeneric.svg file (as we do in some other parts of the UI when we have to show an addon icon and the addon does not have one).

I've attached a patch for doing that in D122207 (and verified locally that with this change browser_html_abuse_report.js doesn't trigger the MOZ_CRASH anymore as expected, and the generic icon seems to fit well in both dark and light themes, by being white when the abuse report panel is dark and black when the abuse report panel has a light white background).

Feel free to add the patch to your stack as is, or to commandeer the patch if you prefer.

(and let me know if there is any other addons-related test that is triggering this diagnostic crash, and I'll take a look asap).

https://hg.mozilla.org/mozilla-central/rev/9d3cf125f605
https://hg.mozilla.org/mozilla-central/rev/9d5d2dc82665
https://hg.mozilla.org/mozilla-central/rev/e4e3098eaf56
https://hg.mozilla.org/mozilla-central/rev/f75f84ad84a5

https://hg.mozilla.org/mozilla-central/rev/cc5556739c43

https://hg.mozilla.org/mozilla-central/rev/675fd489778c

Depends on D122663

https://hg.mozilla.org/mozilla-central/rev/c1f695ba3371
https://hg.mozilla.org/mozilla-central/rev/aaecf2012cb0

Backed out for causing failures on nsJARChannel.

Push with failures

Failure log for a11y failures
Failure log for gv-junit failures
Failure log for gv-junit-fis failures
Failure log for gv-junit-e10s-single failures
Failure log for talos other failures

Backout link

(In reply to Iulian Moraru from comment #25)

Backed out for causing failures on nsJARChannel.

Push with failures

Failure log for a11y failures
Failure log for gv-junit failures
Failure log for gv-junit-fis failures
Failure log for gv-junit-e10s-single failures

Backout link

Huh, clearly it's the tests you didn't know existed that get you - I ran what I thought would have been a pretty comprehensive trypush before landing: https://treeherder.mozilla.org/jobs?repo=try&revision=0372dbe2d3c9f31365675213d5ba0b52a47ad587

I'll look at these some more, but I'm out on PTO for most of the next 4 weeks so it may take me a while...

Backed out changeset 194aa5b57fa7 (Bug 1724718) for causing wpt failures on report-frame-ancestors-with-x-frame-options.sub.html and multiple other.
Backout link
Push with failures <--> wpt17
Failure Log
Also c1 Failure Log
Also wpt32 Failure Log
Also 3 Failure Log
Also C Failure Log
Also wpt16 Failure Log
Also 4 Failure Log
...

Ugh. Seems I need a more extensive try. Let's give that a shot: https://treeherder.mozilla.org/jobs?repo=try&revision=8027b3db6c1aa740712d00d9b8e79eb9ea292259

(In reply to :Gijs (he/him) from comment #29)

Ugh. Seems I need a more extensive try. Let's give that a shot: https://treeherder.mozilla.org/jobs?repo=try&revision=8027b3db6c1aa740712d00d9b8e79eb9ea292259

... it'd help if it was (a) not an artifact try, and (b) on a more recent central. Let's try again: https://treeherder.mozilla.org/jobs?repo=try&revision=577591dbc57cb3bcb3acf9ca930618b4ae7eef8e

https://hg.mozilla.org/mozilla-central/rev/e939a80b5b75
https://hg.mozilla.org/mozilla-central/rev/027ee4c52450