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)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
Firefox 59
Tracking Status
firefox-esr52 57+ fixed
firefox57 blocking fixed
firefox58 + fixed
firefox59 + fixed

People

(Reporter: mconley, Assigned: mconley)

References

Details

Attachments

(7 files, 2 obsolete files)

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.
Attached patch bug1424373.diffSplinter Review
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)
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. :)
(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)
Attachment #8937468 - Flags: review?(dtownsend) → review+
(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.
Flags: needinfo?(liuche)
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)
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.
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
Thanks for flagging this Mike. I've reached out to Marshall over email.
Flags: needinfo?(francois)
https://hg.mozilla.org/mozilla-central/rev/fb2acbf403de
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 59
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?
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 on attachment 8937468 [details] [diff] [review]
bug1424373.diff

ok for beta58.
Attachment #8937468 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
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...
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?
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?
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?
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)
Attachment #8938532 - Flags: review?(dtownsend) → review+
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)
(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?
(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 :)
(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 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+
(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)
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?
(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!
Attachment #8938553 - Attachment is obsolete: true
Attachment #8938564 - Flags: review?(mconley)
Comment on attachment 8938564 [details]
disable-crash-autosubmit@mozilla.org-v2.xpi

Looks good, thanks!
Attachment #8938564 - Flags: review?(mconley) → review+
Ok this makes sense to me now.
Flags: needinfo?(dtownsend)
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)
Attaching notes for QA, so we can update them as needed without resorting to bug comments.
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)
Attachment #8938575 - Attachment description: notes for QA → notes for QA (hotfix)
Please see attached.
Flags: needinfo?(jthomas)
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.
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)
(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)
Attachment #8938575 - Attachment description: notes for QA (hotfix) → notes for QA (system add-on)
Attachment #8938601 - Attachment description: update.xml (v2, for Hotfix) → update.xml (v2, for testing system add-on)
In case someone has a chance to double check the rebase...
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 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+
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+
Blocks: 1427111
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)
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
Depends on: 1427193
Moved the SAO issue to bug 1427193.
Flags: needinfo?(rhelmer)
no need for this to remain confidential
Group: mozilla-employee-confidential
See Also: → 1427066
See Also: 1427066
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.