Also MOZ_CRASH for missing files that go through CreateLocalJarInput helper
Categories
(Firefox :: General, defect)
Tracking
()
People
(Reporter: Gijs, Assigned: Gijs)
References
(Depends on 4 open bugs)
Details
Attachments
(10 files)
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review |
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...
Assignee | ||
Comment 1•3 years ago
|
||
Assignee | ||
Comment 2•3 years ago
|
||
Luca or Mark, the trypush is flagging up this:
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?
Assignee | ||
Comment 3•3 years ago
|
||
Assignee | ||
Comment 4•3 years ago
|
||
Depends on D122162
Assignee | ||
Comment 5•3 years ago
|
||
Depends on D122163
Assignee | ||
Comment 6•3 years ago
|
||
Depends on D122164
Assignee | ||
Comment 7•3 years ago
|
||
Depends on D122165
Assignee | ||
Comment 8•3 years ago
|
||
Depends on D122166
Assignee | ||
Updated•3 years ago
|
Comment 10•3 years ago
|
||
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.
Comment 11•3 years ago
|
||
(In reply to :Gijs (he/him) from comment #2)
Luca or Mark, the trypush is flagging up this:
returns
undefined
in some cases, which means we try to loadchrome://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).
Comment 12•3 years ago
|
||
Comment 13•3 years ago
|
||
Comment 14•3 years ago
|
||
Comment 15•3 years ago
|
||
bugherder |
Comment 16•3 years ago
|
||
Comment 17•3 years ago
|
||
bugherder |
Comment 18•3 years ago
|
||
Comment 19•3 years ago
|
||
bugherder |
Assignee | ||
Comment 20•3 years ago
|
||
Assignee | ||
Comment 21•3 years ago
|
||
Depends on D122663
Comment 22•3 years ago
|
||
Comment 23•3 years ago
|
||
bugherder |
Assignee | ||
Updated•3 years ago
|
Comment 24•3 years ago
|
||
Comment 25•3 years ago
•
|
||
Backed out for causing failures on nsJARChannel.
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
Assignee | ||
Comment 26•3 years ago
|
||
(In reply to Iulian Moraru from comment #25)
Backed out for causing failures on nsJARChannel.
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
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...
Updated•3 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Comment 27•2 years ago
|
||
Comment 28•2 years ago
•
|
||
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
...
Assignee | ||
Comment 29•2 years ago
|
||
Ugh. Seems I need a more extensive try. Let's give that a shot: https://treeherder.mozilla.org/jobs?repo=try&revision=8027b3db6c1aa740712d00d9b8e79eb9ea292259
Assignee | ||
Comment 30•2 years ago
|
||
(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
Comment 31•2 years ago
|
||
Assignee | ||
Comment 32•2 years ago
|
||
Comment 33•2 years ago
|
||
Comment 34•2 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/e939a80b5b75
https://hg.mozilla.org/mozilla-central/rev/027ee4c52450
Updated•2 years ago
|
Description
•