Closed
Bug 1424373
Opened 6 years ago
Closed 6 years ago
Tab crash reporter is activating auto-submission of crash reports anytime a tab crashes with no crash report
Categories
(Firefox :: General, defect)
Firefox
General
Tracking
()
People
(Reporter: mconley, Assigned: mconley)
References
Details
Attachments
(7 files, 2 obsolete files)
7.63 KB,
patch
|
mossop
:
review+
jcristau
:
approval-mozilla-beta+
jcristau
:
approval-mozilla-release+
jcristau
:
approval-mozilla-esr52+
|
Details | Diff | Splinter Review |
9.93 KB,
patch
|
mossop
:
review+
jcristau
:
approval-mozilla-beta+
jcristau
:
approval-mozilla-release+
jcristau
:
approval-mozilla-esr52+
|
Details | Diff | Splinter Review |
1.43 KB,
application/x-xpinstall
|
mconley
:
review+
|
Details |
1.81 KB,
text/plain
|
Details | |
5.31 KB,
application/x-xpinstall
|
Details | |
422 bytes,
text/xml
|
Details | |
14.08 KB,
patch
|
Details | Diff | Splinter Review |
STR: 1) Ensure browser.crashReports.unsubmittedCheck.autoSubmit is false (this is the default, since we want the user to opt-in) 2) Browse a tab somewhere, and make note of its pid 3) Crash the tab in such a way as to not create a crash report. SIGKILL on POSIX OS's, and End Process from the Task Manager on Windows should be enough. 4) You should see a about:tabcrashed page come up, and give you options about closing the tab or restoring it. Note that there are no checkboxes made visible regarding sending crash reports (since no crash report was made) 5) Click on "Restore tab" 6) Check the value of browser.crashReports.unsubmittedCheck.autoSubmit ER: The value of that pref should be false still, since the user never opted into auto-submitting crash reports. AR: The value is true. I think that's because we're hitting this branch: https://searchfox.org/mozilla-central/rev/fd0b701b6f4bce8dead150c569dd68fb9f4c7ed9/browser/modules/ContentCrashHandlers.jsm#488-494 and not sending the requestAutoSubmit argument. Because we don't send that argument along, aboutTabCrashed.js assumes that we don't need to requestAutoSubmit, and that auto submission is already enabled. That sets an internal value in aboutTabCrashed.js for auto-submission, that gets sent back up to ContentCrashHandlers.jsm, and then the pref is set. I've marked this employee confidential right now because this is a bit of a privacy thing - user's are supposed to opt-in to auto-submitting crash reports like this. Users that hit this scenario will automatically send crash reports for crashed background tabs.
Assignee | ||
Comment 1•6 years ago
|
||
This patch makes it so that we ignore / don't set prefs for about:tabcrashed tabs that don't present a report. Hey Mossop, I'm a little worried that we've accidentally opted some users into auto-submitting crash reports. All it would take is for them to be sent to an about:tabcrashed when no report is available. Do you feel like that's worth concern? If so, we might want to consider flipping that pref back for everybody, and having people re-opt-in again. Do you know if there is somebody from the Privacy team that we need to weigh in here?
Assignee: nobody → mconley
Status: NEW → ASSIGNED
Flags: needinfo?(dtownsend)
Attachment #8937468 -
Flags: review?(dtownsend)
Assignee | ||
Comment 2•6 years ago
|
||
Also, Mossop, I only picked on you for this because a bunch of people are on holiday PTO, and I saw some traffic from you in IRC, so I know you're around. :)
Comment 3•6 years ago
|
||
(In reply to Mike Conley (:mconley) (:⚙️) - Backlogged on reviews and needinfos from comment #1) > Created attachment 8937468 [details] [diff] [review] > bug1424373.diff > > This patch makes it so that we ignore / don't set prefs for about:tabcrashed > tabs that don't present a report. > > Hey Mossop, I'm a little worried that we've accidentally opted some users > into auto-submitting crash reports. All it would take is for them to be sent > to an about:tabcrashed when no report is available. How often is that the case? What sort of normal crashes take that form? > Do you feel like that's worth concern? If so, we might want to consider > flipping that pref back for everybody, and having people re-opt-in again. Likely yes, seems like little harm. > Do you know if there is somebody from the Privacy team that we need to weigh > in here? Off the top of my head I'd guess one of the data collection peers: https://wiki.mozilla.org/Firefox/Data_Collection
Flags: needinfo?(dtownsend)
Updated•6 years ago
|
Attachment #8937468 -
Flags: review?(dtownsend) → review+
Assignee | ||
Comment 4•6 years ago
|
||
(In reply to Dave Townsend [:mossop] from comment #3) > > How often is that the case? What sort of normal crashes take that form? > We collect Telemetry in that case via the FX_CONTENT_CRASH_DUMP_UNAVAILABLE histogram. https://mzl.la/2ASNPMH If I'm interpreting this correctly: 1) When users experience a tab crash without a crash report, it usually only happens once per Telemetry session. It's more rare for it to occur more than once per session. 2) The number of Telemetry sessions that report at least one reading of FX_CONTENT_CRASH_DUMP_UNAVAILABLE is somewhere in the neighbourhood of 200k sessions per day on the beta channel. By comparison, we get about ~37M sessions reporting GC_MS (https://mzl.la/2AVabgC). If we use that to calibrate, that's something like < 1% of session pings reporting this condition (this is all napkin math, so put some healthy error bars around this). So I don't think it's super common, but it does occur, and it only needs to occur once for the pref to be accidentally flipped. needinfo'ing liuche from the Data Collection group to advise on how to proceed here.
Assignee | ||
Updated•6 years ago
|
Flags: needinfo?(liuche)
Assignee | ||
Comment 5•6 years ago
|
||
liuche is bogged down with some other stuff, and has suggested I redirect my needinfo? to francois. Hey francois, how do you suggest we proceed here?
Flags: needinfo?(liuche) → needinfo?(francois)
Assignee | ||
Comment 6•6 years ago
|
||
To be clear, I'm asking francois / our Data Collection group about what (if anything) we need to do with the potential population of users that had the pref flipped by accident. With Mossop's r+, I feel confident about landing this patch on central, and I'll do so in a few moments. I'll request uplifts later in the week after it's had a chance to bake.
Assignee | ||
Comment 7•6 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/fb2acbf403de48072409030e72ad61edbed9f803 Bug 1424373 - Don't set crash reporting prefs when showing about:tabcrashed for a crash without a report. r=Mossop
Comment 8•6 years ago
|
||
Thanks for flagging this Mike. I've reached out to Marshall over email.
Flags: needinfo?(francois)
Comment 9•6 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/fb2acbf403de
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
status-firefox59:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → Firefox 59
Assignee | ||
Comment 10•6 years ago
|
||
Comment on attachment 8937468 [details] [diff] [review] bug1424373.diff I'm uncertain if this is worth spinning a point release for, but I think we should at least get this on Beta. I'm meeting with some folks this afternoon to sort through how to approach this, but for now, I'm pre-emptively requesting release channel approval. Approval Request Comment [Feature/Bug causing the regression]: Bug 1309316. [User impact if declined]: Users who experience a tab crash where no report is generated will have a pref flipped accidentally that will opt them in to sending reports for background tab crashes automatically. [Is this code covered by automated tests?]: Yes. [Has the fix been verified in Nightly?]: Yes, I have verified this myself. [Needs manual test from QE? If yes, steps to reproduce]: QE testing on each branch this lands on would be helpful. STR are in comment 0. [List of other uplifts needed for the feature/fix]: None. [Is the change risky?]: No. [Why is the change risky/not risky?]: I'm adding a small piece of code to ignore the case where no crash report is generated, which eliminates the condition where this bug will occur. [String changes made/needed]: None.
Attachment #8937468 -
Flags: approval-mozilla-release?
Attachment #8937468 -
Flags: approval-mozilla-beta?
Assignee | ||
Comment 11•6 years ago
|
||
Comment on attachment 8937468 [details] [diff] [review] bug1424373.diff [Approval Request Comment] If this is not a sec:{high,crit} bug, please state case for ESR consideration: This is a bug where users might accidentally put themselves into a configuration where background tab crash reports are sent automatically, without them explicitly opting in. User impact if declined: See above. Fix Landed on Version: 59.0a1, and requesting approval for 58 and potentially for 57. Risk to taking this patch (and alternatives if risky): Very little risk. String or UUID changes made by this patch: None. See https://wiki.mozilla.org/Release_Management/ESR_Landing_Process for more info.
Attachment #8937468 -
Flags: approval-mozilla-esr52?
Comment 12•6 years ago
|
||
Comment on attachment 8937468 [details] [diff] [review] bug1424373.diff ok for beta58.
Attachment #8937468 -
Flags: approval-mozilla-beta? → approval-mozilla-beta+
Comment 13•6 years ago
|
||
I *think* this'll be wontfix for 57 given the timing. Hopefully we can flip the pref back for affected users when we ship 58...
status-firefox57:
--- → wontfix
status-firefox58:
--- → affected
status-firefox-esr52:
--- → affected
Comment 14•6 years ago
|
||
uplift |
https://hg.mozilla.org/releases/mozilla-beta/rev/0ef7163b1248
Assignee | ||
Comment 15•6 years ago
|
||
Approval Request Comment [Feature/Bug causing the regression]: Bug 1309316. [User impact if declined]: Users that got hit by this bug will continue to inadvertently send background tab crash reports. The earlier patch makes it so that new users don't get into the "bug" state. This patch makes it so that users that have been put into the "bug" state are reset. [Is this code covered by automated tests?]: Yes. [Has the fix been verified in Nightly?]: No. I'm pre-emptively requesting approval. [Needs manual test from QE? If yes, steps to reproduce]: No, the automated test suite should cover this functionality. [List of other uplifts needed for the feature/fix]: Just the other patch in this bug. [Is the change risky?]: No. [Why is the change risky/not risky?]: We're changing the id of a preference, which is very low risk. [String changes made/needed]: None.
Attachment #8938528 -
Flags: review?(dtownsend)
Attachment #8938528 -
Flags: approval-mozilla-release?
Attachment #8938528 -
Flags: approval-mozilla-beta?
Assignee | ||
Comment 16•6 years ago
|
||
Comment on attachment 8938528 [details] [diff] [review] Part 2 - Change the preference name [Approval Request Comment] If this is not a sec:{high,crit} bug, please state case for ESR consideration: This reverts the preference for submitting background crash reports to the default (false - don't send background crash reports). This resets the pref for users in both the "bug" state, as well as users that have legitimately opted into submitting background crash reports. User impact if declined: Users that have gotten into the "bug" state (see STR), will continue to submit background crash reports without explicitly opting in, even if they apply the patch that fixes the bug. Fix Landed on Version: Hopefully 59.0a1 - I just requested review on it. Also requesting approval for 58 and 57. Risk to taking this patch (and alternatives if risky): Very little risk. String or UUID changes made by this patch: None. See https://wiki.mozilla.org/Release_Management/ESR_Landing_Process for more info.
Attachment #8938528 -
Flags: approval-mozilla-esr52?
Assignee | ||
Updated•6 years ago
|
Attachment #8938528 -
Attachment is obsolete: true
Attachment #8938528 -
Flags: review?(dtownsend)
Attachment #8938528 -
Flags: approval-mozilla-release?
Attachment #8938528 -
Flags: approval-mozilla-esr52?
Attachment #8938528 -
Flags: approval-mozilla-beta?
Assignee | ||
Comment 17•6 years ago
|
||
Mossop rightly pointed out that I'd missed updating a test file. I'll re-request approvals ones I get an r+ to avoid noise.
Attachment #8938532 -
Flags: review?(dtownsend)
Updated•6 years ago
|
Attachment #8938532 -
Flags: review?(dtownsend) → review+
Comment 18•6 years ago
|
||
Attached is a system add-on update for Firefox 52->56 (inclusive), for the builds that will not be receiving a dot-release and should have the autosubmit pref forced-off. Since it's not signed, you'll need to use a non-release/non-beta build to test this (I used Nightly). To load it for local testing, you need to set `extensions.legacy.enabled` pref to `false` and then use `about:debugging` to load it (or `about:addons` if you also flip the `xpinstall.signatures.required` pref) You should see that the pref `browser.crashReports.unsubmittedCheck.autoSubmit` is set to `false` immediately on startup of the add-on (which would normally happen very early in application startup), and that attempting to manually flip the pref in `about:config` doesn't work due to the pref observer. Please also have a look inside the XPI and review the code therein :) Thanks! Once this looks good, we'll get it signed and I'll attach instructions for QA.
Attachment #8938553 -
Flags: review?(mconley)
Comment 19•6 years ago
|
||
(In reply to Robert Helmer [:rhelmer] from comment #18) > You should see that the pref > `browser.crashReports.unsubmittedCheck.autoSubmit` is set to `false` > immediately on startup of the add-on (which would normally happen very early > in application startup), and that attempting to manually flip the pref in > `about:config` doesn't work due to the pref observer. So users can't turn on autosubmission at all? Won't that be confusing?
Comment 20•6 years ago
|
||
(In reply to Dave Townsend [:mossop] from comment #19) > (In reply to Robert Helmer [:rhelmer] from comment #18) > > You should see that the pref > > `browser.crashReports.unsubmittedCheck.autoSubmit` is set to `false` > > immediately on startup of the add-on (which would normally happen very early > > in application startup), and that attempting to manually flip the pref in > > `about:config` doesn't work due to the pref observer. > > So users can't turn on autosubmission at all? Won't that be confusing? This is only for users that aren't going to be getting a dot-release and are unsupported releases. That's my understanding of what's wanted from chatting w/ mconley so I'll defer to him :)
Assignee | ||
Comment 21•6 years ago
|
||
(In reply to Robert Helmer [:rhelmer] from comment #20) > > So users can't turn on autosubmission at all? Won't that be confusing? > > This is only for users that aren't going to be getting a dot-release and are > unsupported releases. > > That's my understanding of what's wanted from chatting w/ mconley so I'll > defer to him :) For users that get the hotfix and don't upgrade to get dot release or onto 58+, yes, that's what will happen. Specifically: 1) If the user visits about:preferences, goes to the Privacy and Security section, and tries to check the "Allow {brandShortName} to send crash reports to Mozilla" to true, it will not work. It'll stay unchecked. 2) If a tab crashes, it will show a "Update preferences to automatically submit reports when {brandShortName} crashes". If the user checks that, it will be checked, but next time a tab crashes, that checkbox will appear again and be unchecked. This, to me, is the simplest solution to stopping old builds from sending these crash reports.
Assignee | ||
Comment 22•6 years ago
|
||
Comment on attachment 8938553 [details] disable-crash-autosubmit@mozilla.org-v1.xpi I've just tested the hotfix on Nightly, and it appears to do the job. If you want to be pedantic about it, there's a 4 space indent inside the setting of the pref block: Services.prefs.addObserver(AUTO_SUBMIT_PREF, (subject, topic, data) => { if (topic == "nsPref:changed" && data == AUTO_SUBMIT_PREF) { Services.prefs.setBoolPref(AUTO_SUBMIT_PREF, false); } }); which should be a 2-space indent, but smallllll potatoes. One thing though is the install.rdf targets a min version of 52.*, and a max version of 56.*. Shouldn't this target a max of 57.0.2?
Attachment #8938553 -
Flags: review?(mconley) → review+
Assignee | ||
Comment 23•6 years ago
|
||
(In reply to Mike Conley (:mconley) (:⚙️) - Backlogged on reviews and needinfos from comment #21) > For users that get the hotfix and don't upgrade to get dot release or onto > 58+, yes, that's what will happen. Specifically: > > 1) If the user visits about:preferences, goes to the Privacy and Security > section, and tries to check the "Allow {brandShortName} to send crash > reports to Mozilla" to true, it will not work. It'll stay unchecked. > 2) If a tab crashes, it will show a "Update preferences to automatically > submit reports when {brandShortName} crashes". If the user checks that, it > will be checked, but next time a tab crashes, that checkbox will appear > again and be unchecked. > > This, to me, is the simplest solution to stopping old builds from sending > these crash reports. To be clear, do you think this is a sufficient solution for the builds that don't get the patch, Mossop?
Flags: needinfo?(dtownsend)
Assignee | ||
Comment 24•6 years ago
|
||
Comment on attachment 8938532 [details] [diff] [review] Patch to reset the pref See comment 15 and comment 16.
Attachment #8938532 -
Flags: approval-mozilla-release?
Attachment #8938532 -
Flags: approval-mozilla-esr52?
Attachment #8938532 -
Flags: approval-mozilla-beta?
Comment 25•6 years ago
|
||
(In reply to Mike Conley (:mconley) (:⚙️) - Backlogged on reviews and needinfos from comment #22) > Comment on attachment 8938553 [details] > disable-crash-autosubmit@mozilla.org-v1.xpi > > I've just tested the hotfix on Nightly, and it appears to do the job. If you > want to be pedantic about it, there's a 4 space indent inside the setting of > the pref block: > > Services.prefs.addObserver(AUTO_SUBMIT_PREF, (subject, topic, data) => { > if (topic == "nsPref:changed" && data == AUTO_SUBMIT_PREF) { > Services.prefs.setBoolPref(AUTO_SUBMIT_PREF, false); > } > }); > > which should be a 2-space indent, but smallllll potatoes. The perils of developing out of tree w/o eslint :/ Thanks. > > One thing though is the install.rdf targets a min version of 52.*, and a max > version of 56.*. Shouldn't this target a max of 57.0.2? OK thanks I'll make max 57.0.2 ... note that this really is just an extra layer of protection since we can control exactly who gets it via the update server, but we do need to make it inclusive enough. Thanks!
Comment 26•6 years ago
|
||
Attachment #8938553 -
Attachment is obsolete: true
Attachment #8938564 -
Flags: review?(mconley)
Assignee | ||
Comment 27•6 years ago
|
||
Comment on attachment 8938564 [details] disable-crash-autosubmit@mozilla.org-v2.xpi Looks good, thanks!
Attachment #8938564 -
Flags: review?(mconley) → review+
Comment 29•6 years ago
|
||
Comment on attachment 8938564 [details] disable-crash-autosubmit@mozilla.org-v2.xpi Can you please sign this system add-on update? Please don't post the result anywhere public (do not host on the staging server etc) Attaching to this bug would be great. Thanks!
Flags: needinfo?(rdalal)
Flags: needinfo?(mcooper)
Comment 30•6 years ago
|
||
Attaching notes for QA, so we can update them as needed without resorting to bug comments.
Comment 31•6 years ago
|
||
I don't have access to sign system addons only regular/study addons. NI'ing jason.
Flags: needinfo?(rdalal)
Flags: needinfo?(mcooper)
Flags: needinfo?(jthomas)
Updated•6 years ago
|
Attachment #8938575 -
Attachment description: notes for QA → notes for QA (hotfix)
Comment 33•6 years ago
|
||
This is the update.xml for local testing mentioned in the notes for QA (hotfix) attachment. Please note that the URL in this file must be changed to point at the signed XPI file also attached to this bug. As mentioned in the QA notes, please do not make any of this public (pastebin, etherpad, etc) including output from Browser Console - attach it to this bug instead. Thanks!
I've talked a bit with mconley and lonnen and I think we should not rush to a dot release. In fact I would like to hold off on uplift until we are closer to the release date, which I think we could aim at the 27th or 28th. If this situation were simple (a security exploit) we could rush it. For this, it sounds like we want to be very sure of what we're doing on the client (Firefox) side and for the crash stats collecting system. It's late Friday afternoon coming into the holidays. So I'm not uplifting for the moment - it won't help us over the weekend to have done that part now. cc-ing Sylvestre with dcamp's permission, and I will send him and julien a summary email.
One question I have that you may have already discussed on irc. Here's what I understand of what this is doing and what data may be affected, * For early beta, dev ed, and nightly, we look for unsubmitted crash reports on startup. I think those crash reports could be tab (content) crashes or browser crashes. * For late beta and release, this would be only crash reports submitted for a tab that wasn’t active and had a content crash. A background crash report is strictly a tab that crashed while you weren't looking at it. * Not sure about ESR. I'm wondering if we know for sure that only content crashes would have been reported from late beta and release. If so, we might be able to keep browser crash data for those versions/channels.
What about Fennec data?
Comment 38•6 years ago
|
||
We've been calling this a hotfix, and there is both a system add on and an update.xml defining the hotfix. I've gotten a few questions along the lines of, "Why a hotfix and not a system addon?" Could you lay out some details about the approach here?
Flags: needinfo?(rhelmer)
Comment 39•6 years ago
|
||
(In reply to Lonnen :lonnen from comment #38) > We've been calling this a hotfix, and there is both a system add on and an > update.xml defining the hotfix. I've gotten a few questions along the lines > of, "Why a hotfix and not a system addon?" > > Could you lay out some details about the approach here? Sure. We used to have a single "hotfix" add-on that could be served to Firefox by AMO, which we don't use anymore. It's been replaced by serving individual system add-on updates (one for each fix). This is documented in https://firefox-source-docs.mozilla.org/toolkit/mozapps/extensions/addon-manager/SystemAddons.html#system-add-on-updates I'll change the names in the attachment for consistency... it'd be great to figure out a name which doesn't have the same baggage as "hotfix"!
Flags: needinfo?(rhelmer)
Updated•6 years ago
|
Attachment #8938575 -
Attachment description: notes for QA (hotfix) → notes for QA (system add-on)
Updated•6 years ago
|
Attachment #8938601 -
Attachment description: update.xml (v2, for Hotfix) → update.xml (v2, for testing system add-on)
Comment 40•6 years ago
|
||
In case someone has a chance to double check the rebase...
Assignee | ||
Comment 41•6 years ago
|
||
Comment on attachment 8938839 [details] [diff] [review] patches rebased to esr52 Review of attachment 8938839 [details] [diff] [review]: ----------------------------------------------------------------- I did a cross-check against the two patches. This looks to me to have everything - although a small nit with the test. ::: browser/base/content/test/tabcrashed/browser_autoSubmitRequest.js @@ +107,5 @@ > + yield SpecialPowers.pushPrefEnv({ > + set: [[AUTOSUBMIT_PREF, false]], > + }); > + > + return BrowserTestUtils.withNewTab({ You need to turn this return into a yield, otherwise we never get to line 151. ::: browser/modules/ContentCrashHandlers.jsm @@ +329,5 @@ > * Note that it is expected that all properties are set, > * even if they are empty. > */ > maybeSendCrashReport(message) { > + if (!AppConstants.MOZ_CRASHREPORTER) { Kinda weird that there are 2 patch entries for ContentCrashHandlers.jsm here, but if Mercurial likes it, I guess it's fine. I don't think Splinter likes it, fwiw.
cc-ing Andrei and Florin since they will need to be in this bug for making a test plan and general QA.
Comment 43•6 years ago
|
||
Comment on attachment 8937468 [details] [diff] [review] bug1424373.diff let's fix this in release and esr.
Attachment #8937468 -
Flags: approval-mozilla-release?
Attachment #8937468 -
Flags: approval-mozilla-release+
Attachment #8937468 -
Flags: approval-mozilla-esr52?
Attachment #8937468 -
Flags: approval-mozilla-esr52+
Updated•6 years ago
|
Attachment #8938532 -
Flags: approval-mozilla-release?
Attachment #8938532 -
Flags: approval-mozilla-release+
Attachment #8938532 -
Flags: approval-mozilla-esr52?
Attachment #8938532 -
Flags: approval-mozilla-esr52+
Attachment #8938532 -
Flags: approval-mozilla-beta?
Attachment #8938532 -
Flags: approval-mozilla-beta+
Comment 44•6 years ago
|
||
uplift |
https://hg.mozilla.org/releases/mozilla-beta/rev/de57ad2b9bc57fa27ba986b07ca64b1323633524
Comment 45•6 years ago
|
||
uplift |
https://hg.mozilla.org/releases/mozilla-release/rev/9727737210d1e069a6dbc08cd303376b642ecd14 https://hg.mozilla.org/releases/mozilla-release/rev/c548334d172bd937da77e36867473d861cfa2217
Comment 46•6 years ago
|
||
uplift |
FIREFOX_ESR_52_5_X_RELBRANCH: remote: https://hg.mozilla.org/releases/mozilla-esr52/rev/e205b8b753b5fac353ab93a90fac78525aacb7c4 remote: https://hg.mozilla.org/releases/mozilla-esr52/rev/ac091dfca5936831201046c95e8f8eeb09b15d05 remote: https://hg.mozilla.org/releases/mozilla-esr52/rev/292a2d5bcb1f4a07e875b0b60a925f31992e898f default: remote: https://hg.mozilla.org/releases/mozilla-esr52/rev/320032aaa06899f5585dcd0288059e5342118714 remote: https://hg.mozilla.org/releases/mozilla-esr52/rev/19ea736e7e3d20555ee6633b9d7803c1225979e1
Comment 47•6 years ago
|
||
We created a Test Plan[1] for this issue and managed to give it a run. However, there are some issues we need clarification on. The most concerning one is that the SAO is not compatible with Fx 52 (it seems it works starting with Fx 55). Please take a look over our results and feel free to comment and let us know where we can provide additional information. [1] https://goo.gl/Pq4wwD
Flags: needinfo?(rhelmer)
Comment 48•6 years ago
|
||
To expand on comment 47, it looks like the SAO won't install on 52 with: 1514387923034 addons.xpi WARN Add-on disable-crash-autosubmit@mozilla.org is not compatible with application version. 1514387923035 addons.xpi WARN System add-on disable-crash-autosubmit@mozilla.org isn't compatible with the application. 1514387923035 addons.manager WARN Failed to update system addons: Error: Rejecting updated system add-on set that either could not be downloaded or contained unusable add-ons. (resource://gre/modules/addons/XPIProvider.jsm:3228:13) JS Stack trace: this.XPIProvider.updateSystemAddons<@XPIProvider.jsm:3228:13 On 53 and 54, it fails due to what looks like the API change from bug 1355216: 1514388757431 addons.xpi DEBUG Loading bootstrap scope from /tmp/home/.mozilla/firefox/gmwojqyj.default/features/{ed8a465b-a79c-4482-9d17-51b7edeb3764}/disable-crash-autosubmit@mozilla.org.xpi 1514388757440 addons.xpi DEBUG Calling bootstrap method install on disable-crash-autosubmit@mozilla.org version 2.0 1514388757443 addons.xpi DEBUG Install of file:///tmp/tmpaddon-847177 completed. 1514388757443 addons.xpi DEBUG Registering manifest for /tmp/home/.mozilla/firefox/gmwojqyj.default/features/{ed8a465b-a79c-4482-9d17-51b7edeb3764}/disable-crash-autosubmit@mozilla.org.xpi 1514388757443 addons.xpi DEBUG Calling bootstrap method startup on disable-crash-autosubmit@mozilla.org version 2.0 1514388757444 addons.xpi WARN Exception running bootstrap method startup on disable-crash-autosubmit@mozilla.org: [Exception... "Not enough arguments [nsIPrefBranch.addObserver]" nsresult: "0x80570001 (NS_ERROR_XPC_NOT_ENOUGH_ARGS)" location: "JS frame :: resource://gre/modules/addons/XPIProvider.jsm -> jar:file:///tmp/home/.mozilla/firefox/gmwojqyj.default/features/%7Bed8a465b-a79c-4482-9d17-51b7edeb3764%7D/disable-crash-autosubmit@mozilla.org.xpi!/bootstrap.js :: startup :: line 22" data: no] Stack trace: startup()@resource://gre/modules/addons/XPIProvider.jsm -> jar:file:///tmp/home/.mozilla/firefox/gmwojqyj.default/features/%7Bed8a465b-a79c-4482-9d17-51b7edeb3764%7D/disable-crash-autosubmit@mozilla.org.xpi!/bootstrap.js:22 < callBootstrapMethod()@resource://gre/modules/addons/XPIProvider.jsm:4903 < startInstall/<()@resource://gre/modules/addons/XPIProvider.jsm:5811 < TaskImpl_run()@resource://gre/modules/Task.jsm:319 < process()@resource://gre/modules/Promise.jsm -> resource://gre/modules/Promise-backend.js:917 < walkerLoop()@resource://gre/modules/Promise.jsm -> resource://gre/modules/Promise-backend.js:801 < scheduleWalkerLoop/<()@resource://gre/modules/Promise.jsm -> resource://gre/modules/Promise-backend.js:737
Updated•6 years ago
|
tracking-firefox57:
--- → blocking
tracking-firefox58:
--- → +
tracking-firefox59:
--- → +
tracking-firefox-esr52:
--- → 57+
Comment 50•6 years ago
|
||
no need for this to remain confidential
Group: mozilla-employee-confidential
Comment 51•6 years ago
|
||
I have reproduced this bug with Nightly 59.0a1 (2017-12-08) on Windows 10 , 64 Bit ! This bug's fix is Verified with latest Beta ! Build ID 20180215111455 User Agent Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:59.0) Gecko/20100101 Firefox/59.0
QA Whiteboard: [testday-20180216]
You need to log in
before you can comment on or make changes to this bug.
Description
•