1424373 - Tab crash reporter is activating auto-submission of crash reports anytime a tab crashes with no crash report

Status: RESOLVED FIXED

(Firefox :: General, defect)

Description

[Mike Conley (:mconley) (:⚙️)]

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.

Comment 1

[Mike Conley (:mconley) (:⚙️)]

Attachment: 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.

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?

Comment 2

[Mike Conley (:mconley) (:⚙️)]

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

[Dave Townsend [:mossop]]

(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

Comment 4

[Mike Conley (:mconley) (:⚙️)]

(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.

Comment 5

[Mike Conley (:mconley) (:⚙️)]

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?

Comment 6

[Mike Conley (:mconley) (:⚙️)]

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.

Comment 7

[Mike Conley (:mconley) (:⚙️)]

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

[François Marier [:francois]]

Thanks for flagging this Mike. I've reached out to Marshall over email.

Comment 9

[Ryan VanderMeulen [:RyanVM]]

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

Comment 10

[Mike Conley (:mconley) (:⚙️)]

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.

Comment 11

[Mike Conley (:mconley) (:⚙️)]

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.

Comment 12

[Julien Cristau [:jcristau]]

Comment on attachment 8937468 [details] [diff] [review]
bug1424373.diff

ok for beta58.

Comment 13

[Julien Cristau [:jcristau]]

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...

Comment 14

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-beta/rev/0ef7163b1248

Comment 15

[Mike Conley (:mconley) (:⚙️)]

Attachment: Part 2 - Change the preference name

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.

Comment 16

[Mike Conley (:mconley) (:⚙️)]

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.

Comment 17

[Mike Conley (:mconley) (:⚙️)]

Attachment: Patch to reset the pref

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.

Comment 18

[Robert Helmer [:rhelmer]]

Attachment: [e-mail]

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.

Comment 19

[Dave Townsend [:mossop]]

(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

[Robert Helmer [:rhelmer]]

(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 :)

Comment 21

[Mike Conley (:mconley) (:⚙️)]

(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.

Comment 22

[Mike Conley (:mconley) (:⚙️)]

Comment on attachment 8938553 [details]
[e-mail]

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?

Comment 23

[Mike Conley (:mconley) (:⚙️)]

(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?

Comment 24

[Mike Conley (:mconley) (:⚙️)]

Comment on attachment 8938532 [details] [diff] [review]
Patch to reset the pref

See comment 15 and comment 16.

Comment 25

[Robert Helmer [:rhelmer]]

(In reply to Mike Conley (:mconley) (:⚙️) - Backlogged on reviews and needinfos from comment #22)
> Comment on attachment 8938553 [details]
> [e-mail]
> 
> 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

[Robert Helmer [:rhelmer]]

Attachment: [e-mail]

Comment 27

[Mike Conley (:mconley) (:⚙️)]

Comment on attachment 8938564 [details]
[e-mail]

Looks good, thanks!

Comment 28

[Dave Townsend [:mossop]]

Ok this makes sense to me now.

Comment 29

[Robert Helmer [:rhelmer]]

Comment on attachment 8938564 [details]
[e-mail]

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!

Comment 30

[Robert Helmer [:rhelmer]]

Attachment: notes for QA (system add-on)

Attaching notes for QA, so we can update them as needed without resorting to bug comments.

Comment 31

[Rehan Dalal (Inactive)]

I don't have access to sign system addons only regular/study addons.

NI'ing jason.

Comment 32

[Jason Thomas [:jason]]

Attachment: [e-mail] signed

Please see attached.

Comment 33

[Robert Helmer [:rhelmer]]

Attachment: update.xml (v2, for testing system add-on)

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!

Comment 34

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

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

Comment 35

[Liz Henry (:lizzard Please n-i to RyanVM, jcristau, or pascal)]

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.

Comment 36

[Liz Henry (:lizzard Please n-i to RyanVM, jcristau, or pascal)]

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.

Comment 37

[Liz Henry (:lizzard Please n-i to RyanVM, jcristau, or pascal)]

What about Fennec data?

Comment 38

[Lonnen :lonnen]

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?

Comment 39

[Robert Helmer [:rhelmer]]

(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"!

Comment 40

[Julien Cristau [:jcristau]]

Attachment: patches rebased to esr52

In case someone has a chance to double check the rebase...

Comment 41

[Mike Conley (:mconley) (:⚙️)]

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.

Comment 42

[Liz Henry (:lizzard Please n-i to RyanVM, jcristau, or pascal)]

cc-ing Andrei and Florin since they will need to be in this bug for making a test plan and general QA.

Comment 43

[Julien Cristau [:jcristau]]

Comment on attachment 8937468 [details] [diff] [review]
bug1424373.diff

let's fix this in release and esr.

Comment 44

[Julien Cristau [:jcristau]]

https://hg.mozilla.org/releases/mozilla-beta/rev/de57ad2b9bc57fa27ba986b07ca64b1323633524

Comment 45

[Julien Cristau [:jcristau]]

https://hg.mozilla.org/releases/mozilla-release/rev/9727737210d1e069a6dbc08cd303376b642ecd14
https://hg.mozilla.org/releases/mozilla-release/rev/c548334d172bd937da77e36867473d861cfa2217

Comment 46

[Julien Cristau [:jcristau]]

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

[Cornel Ionce [:noni] [Hubs QA]]

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

Comment 48

[Julien Cristau [:jcristau]]

To expand on comment 47, it looks like the SAO won't install on 52 with:

1514387923034	addons.xpi	WARN	Add-on [e-mail] is not compatible with application version.
1514387923035	addons.xpi	WARN	System add-on [e-mail] 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}/[e-mail]
1514388757440	addons.xpi	DEBUG	Calling bootstrap method install on [e-mail] 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}/[e-mail]
1514388757443	addons.xpi	DEBUG	Calling bootstrap method startup on [e-mail] version 2.0
1514388757444	addons.xpi	WARN	Exception running bootstrap method startup on [e-mail]: [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/[e-mail]!/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/[e-mail]!/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

Comment 49

[Julien Cristau [:jcristau]]

Moved the SAO issue to bug 1427193.

Comment 50

[Lonnen :lonnen]

no need for this to remain confidential

Comment 51

[Sajedul Islam]

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