Closed
Bug 1420594
Opened 7 years ago
Closed 7 years ago
Regression: Latest Nightly needs a longer time to Quit (Spinning Beach Ball appears)
Categories
(Core :: DOM: Core & HTML, defect)
Tracking
()
RESOLVED
FIXED
mozilla59
Tracking | Status | |
---|---|---|
firefox-esr52 | --- | unaffected |
firefox57 | --- | unaffected |
firefox58 | --- | unaffected |
firefox59 | --- | fixed |
People
(Reporter: mehmet.sahin, Assigned: bkelly)
References
Details
(Keywords: nightly-community, perf, regression)
Attachments
(6 files, 8 obsolete files)
550.43 KB,
video/quicktime
|
Details | |
1.07 MB,
video/quicktime
|
Details | |
7.68 KB,
image/png
|
Details | |
6.78 KB,
patch
|
baku
:
review+
|
Details | Diff | Splinter Review |
8.12 KB,
patch
|
bkelly
:
review+
|
Details | Diff | Splinter Review |
928 bytes,
patch
|
bkelly
:
review+
|
Details | Diff | Splinter Review |
macOS 10.12.6 FF Nightly 59.0a1 (2017-11-25) (64-Bit) 1.) Start Nightly 2.) Quit Nightly via CMD-Q Actual: Nightly needs a longer time to Quit. The Spinning Beach Ball appears. Expected: Nightly should quit quickly. This is a regression.
Summary: Regression: Lastet Nightly needs a longer time to Quit (Spinning Beach Ball) → Regression: Latest Nightly needs a longer time to Quit (Spinning Beach Ball appears)
I did a bisect, and it looks like I found the regression range: Good: 2017-11-22-10-31-38 Bad: 2017-11-22-22-00-56 May be you can help to find the culprit in this range that could have cause this regression. Thanks.
Comment 2•7 years ago
|
||
Can you please use https://mozilla.github.io/mozregression/ to determine a specific bug introduced the regression?
Mozregression seems to be a Windows GUI. Since this is a macOS bug, is it possible to use it on macOS too? If yes, do you have a documentation? I found the regression range above via downloading them manually from https://ftp.mozilla.org/pub/firefox/nightly/2017/. Thank you.
And here is a actual Screencast. Nightly quits in 7 sec. :-( If you need more information please let me know.
I can reproduce this on Windows 10, Ubuntu 17.04 and macOS 10.13.1. Regression range: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=e6ace8b5531cd2f50b6685ef8fdb180afcd9344e&tochange=dbbca05aa64a14580d3ab23950e148019a097218
Blocks: 1419536
Has Regression Range: --- → yes
status-firefox58:
--- → unaffected
OS: Mac OS X → All
Hardware: Unspecified → All
(In reply to magicp from comment #6) > I can reproduce this on Windows 10, Ubuntu 17.04 and macOS 10.13.1. > > Regression range: > https://hg.mozilla.org/integration/mozilla-inbound/ > pushloghtml?fromchange=e6ace8b5531cd2f50b6685ef8fdb180afcd9344e&tochange=dbbc > a05aa64a14580d3ab23950e148019a097218 Thanks for the regression range. bkelly@, Could you please take a look at this regression? Thank you in advance!
Flags: needinfo?(bkelly)
Assignee | ||
Comment 8•7 years ago
|
||
I'll investigate first thing tomorrow morning.
(In reply to Ben Kelly [:bkelly] from comment #8) > I'll investigate first thing tomorrow morning. Okay, thank you very much.
Assignee | ||
Comment 10•7 years ago
|
||
My theory is my changes introduced too much IPC traffic late in shutdown. My plan is to try eagerly shutting down ClientManagerService and all its actors at the first signs of shutdown. A back up plan is to filter out window/worker clients we don't technically need yet. I want to avoid this since it limits the usefulness of this code going forward, but it might be a reasonable back up plan for now. Of course, it could also be something completely different that I broke. I'll see what works tomorrow.
Assignee | ||
Comment 11•7 years ago
|
||
(In reply to magicp from comment #6) > I can reproduce this on Windows 10, Ubuntu 17.04 and macOS 10.13.1. What were you looking for on windows? I can't reproduce on that platform. Watching task manager it seems to go away immediately.
Flags: needinfo?(magicp.jp)
Assignee | ||
Comment 12•7 years ago
|
||
Hmm, I think I might be able to reproduce something on linux.
Assignee: nobody → bkelly
Status: NEW → ASSIGNED
Flags: needinfo?(magicp.jp)
Flags: needinfo?(bkelly)
Reporter | ||
Comment 13•7 years ago
|
||
Ben: If you need some information from the Mac side (Repro steps etc.) I can provide. Thanks.
Assignee | ||
Comment 14•7 years ago
|
||
And I can confirm at rev e6ace8b5531c the delay I see is gone. I'll investigate. (In reply to Mehmet from comment #13) > Ben: If you need some information from the Mac side (Repro steps etc.) I can > provide. Thanks. Thanks, but I think I have enough information to proceed now.
Comment 15•7 years ago
|
||
(In reply to Ben Kelly [:bkelly] from comment #11) > What were you looking for on windows? I can't reproduce on that platform. > Watching task manager it seems to go away immediately. It is easy steps, quit and restart Firefox. Then a message will be shown. "Firefox is already running, but is not responding. The old Firefox process must be closed to open a new window [Close Firefox][Cancel]"
Assignee | ||
Comment 16•7 years ago
|
||
Assignee | ||
Comment 17•7 years ago
|
||
This fixes the problem for me locally. Lets see if it blows anything up on try: https://treeherder.mozilla.org/#/jobs?repo=try&revision=62269b6c4492abff89d8c1778474e83433dcbff6
Assignee | ||
Comment 18•7 years ago
|
||
Fix some static analysis bustage. https://treeherder.mozilla.org/#/jobs?repo=try&revision=0ef960c14cd7314ad8c65b2397d83aeacef0c16e
Attachment #8932619 -
Attachment is obsolete: true
Assignee | ||
Comment 19•7 years ago
|
||
Does this test build fix the issue for you? https://queue.taskcluster.net/v1/task/I9BZpgUkR9KMa8liN1aAjg/runs/0/artifacts/public/build/target.dmg Note, you have to temporarily disable application code signing to run it on mac. For example: https://apple.stackexchange.com/a/294016
Flags: needinfo?(mehmet.sahin)
Assignee | ||
Comment 20•7 years ago
|
||
Hmm, lots of orange. It seems before-profile-change does not always fire. I'll try switching to NS_XPCOM_WILL_SHUTDOWN_OBSERVER_ID tomorrow.
Assignee | ||
Comment 21•7 years ago
|
||
Nevermind. This binary crashes immediately on my mac.
Flags: needinfo?(mehmet.sahin)
Reporter | ||
Comment 22•7 years ago
|
||
Hello Ben, I was able to install the target.dmg on my MacBook Air 11 (Mid 2012) without a crasher. Quitting the app worked also fine and quick again as expected. Okay, since you noticed the crasher in that build I will wait then for a new build from you to test again. Thanks.
Assignee | ||
Comment 23•7 years ago
|
||
https://treeherder.mozilla.org/#/jobs?repo=try&revision=81625730215c5e96d1d5b5947543d96cbabfff0e
Attachment #8932628 -
Attachment is obsolete: true
Assignee | ||
Comment 24•7 years ago
|
||
Running into problems because of bug 1421712. I'll have to refactor this a bit.
Assignee | ||
Comment 25•7 years ago
|
||
Switch to using nsIAsyncShutdown service since it tells me if the observer topic has already fired. https://treeherder.mozilla.org/#/jobs?repo=try&revision=bc4b733cdc4add341d19d92dd51d057a1f34194a
Assignee | ||
Comment 26•7 years ago
|
||
https://treeherder.mozilla.org/#/jobs?repo=try&revision=43dcbfa70d21fdadee10ee16ed5ef5ffef339179
Attachment #8932922 -
Attachment is obsolete: true
Attachment #8933008 -
Attachment is obsolete: true
Assignee | ||
Comment 27•7 years ago
|
||
Comment on attachment 8932617 [details] [diff] [review] P1 Make ClientManagerService track active ClientManagerParent actors. r=baku Andrea, this patch makes us track the top level PClientManagerParent actors in a list on the ClientManagerService. This list will be used in the next patch to kill these actors at the start of the shutdown process. I also added an Init() method so I can kill the actor immediately if shutdown has already begun.
Attachment #8932617 -
Flags: review?(amarchesini)
Assignee | ||
Comment 28•7 years ago
|
||
Comment on attachment 8933037 [details] [diff] [review] P2 Eagerly shutdown ClientManagerService. r=baku This patch adds an nsIAsyncShutdownBlocker that resolves a MozPromise when xpcom-shutdown is reached. This then causes the ClientManagerService on the background thread to start deleting the PClientManagerParent actors which in turn stops all Client IPC actors. We don't actually block shutdown, though. We don't currently leak without listening to shutdown since the service is gracefully ref-counted away as windows are destroyed. We only really care about shutdown as a way to jump start the teardown to avoid IPC traffic late in the process. Note, this does hold the ClientManagerService alive until shutdown, but we effectively do that anyway since every window object in the system holds it alive.
Attachment #8933037 -
Flags: review?(amarchesini)
Comment 29•7 years ago
|
||
Please correct the component if this does not fit. Thanks.
Component: Untriaged → General
Product: Firefox → Core
Assignee | ||
Updated•7 years ago
|
Component: General → DOM
Updated•7 years ago
|
Attachment #8932617 -
Flags: review?(amarchesini) → review+
Updated•7 years ago
|
Attachment #8933037 -
Flags: review?(amarchesini) → review+
Comment 30•7 years ago
|
||
Pushed by bkelly@mozilla.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/ff3ee0cc91ab P1 Make ClientManagerService track active ClientManagerParent actors. r=baku https://hg.mozilla.org/integration/mozilla-inbound/rev/007fde92382e P2 Eagerly shutdown ClientManagerService. r=baku
Comment 31•7 years ago
|
||
Backed out 2 changesets (bug 1420594) for leaks in browser-chrome tests r=backout on a CLOSED TREE https://treeherder.mozilla.org/#/jobs?repo=mozilla-inbound&filter-resultStatus=testfailed&filter-resultStatus=busted&filter-resultStatus=exception&filter-classifiedState=unclassified&selectedJob=148802761 https://hg.mozilla.org/integration/mozilla-inbound/rev/bf442ce2403cde590b8c8f2c6a346a9862bc2950
Flags: needinfo?(bkelly)
Assignee | ||
Comment 32•7 years ago
|
||
https://treeherder.mozilla.org/#/jobs?repo=try&revision=24fcee31168b75b358452e8bf43b8cc01314941d
Flags: needinfo?(bkelly)
Assignee | ||
Comment 33•7 years ago
|
||
https://treeherder.mozilla.org/#/jobs?repo=try&revision=485de16183c06b43d75f282d80b5f6c2726ea586
Attachment #8933358 -
Attachment is obsolete: true
Assignee | ||
Updated•7 years ago
|
Attachment #8933360 -
Attachment is obsolete: true
Assignee | ||
Comment 34•7 years ago
|
||
https://treeherder.mozilla.org/#/jobs?repo=try&revision=bc974aa8737462bc17cf4296a5af97d73e43088e
Attachment #8933037 -
Attachment is obsolete: true
Assignee | ||
Updated•7 years ago
|
Attachment #8933411 -
Flags: review+
Assignee | ||
Comment 35•7 years ago
|
||
https://treeherder.mozilla.org/#/jobs?repo=try&revision=b033d1ee63fc927de73399351b96414ce4dfc6d0
Attachment #8933411 -
Attachment is obsolete: true
Attachment #8933414 -
Flags: review+
Assignee | ||
Comment 36•7 years ago
|
||
https://treeherder.mozilla.org/#/jobs?repo=try&revision=f08b8f003213eb1182c6d7df6db21df72b59ddc1
Assignee | ||
Comment 37•7 years ago
|
||
These leaks are so weird. Its like something landed that depends on clients API delaying shutdown and when I fix that its uncovering that new problem.
Assignee | ||
Comment 38•7 years ago
|
||
Let's see if just disabling ClientSource creation added in bug 1419536 also triggers these leaks.
Comment 39•7 years ago
|
||
I am having a similar problem but I don't have any visual indication that Fx hasn't quit. Please look at the bug report I opened regarding my problem: https://bugzilla.mozilla.org/show_bug.cgi?id=1420995
Assignee | ||
Comment 40•7 years ago
|
||
(In reply to Gary [:streetwolf] from comment #39) > I am having a similar problem but I don't have any visual indication that Fx > hasn't quit. > > Please look at the bug report I opened regarding my problem: > https://bugzilla.mozilla.org/show_bug.cgi?id=1420995 I'm going to dupe it to here. Thanks for pointing it out.
Assignee | ||
Comment 42•7 years ago
|
||
Try some other changes to try avoid these leaks: https://treeherder.mozilla.org/#/jobs?repo=try&revision=ee6b223d134b2c7174c37b98ff43d7067d5ea602
Assignee | ||
Comment 43•7 years ago
|
||
Jan-Ivar, can you help me figure out why content/test/webrtc tests are leaking in my try builds? Some context: 1. Last week I landed bug 1419536 2. This bug is because that landing introduced a delay in shutdown. The browser now takes many extra seconds to stop. 3. When I fix the shutdown delay I get leaks in webrtc tests. 4. When I disable the code from bug 1419536 I get leaks in webrtc tests. Did something land in webrtc in the last week? Is it possible that its relying on the slow shutdown to cleanup properly? Right now I don't even know where to look.
Flags: needinfo?(jib)
Assignee | ||
Comment 44•7 years ago
|
||
For example of leaks, see: https://treeherder.mozilla.org/#/jobs?repo=try&revision=063607ce22c1fc16a29c0bdc392143681382dcbd
Comment 45•7 years ago
|
||
I see HTMLMediaElement::ShutdownObserver and MediaStreamGraph in comment 44 and on Windows as well in https://treeherder.mozilla.org/logviewer.html#?job_id=148926257&repo=try&lineNumber=10253 My initial suspicion given the 5 day time window was the CamerasParent reorg in bug 1399413 and bug 1388667, which backends getUserMedia calls, which are being exercised in the problematic tests in browser/base/content/test/webrtc/ (UI permission prompt tests that call getUserMedia). But with these leaks happening on Windows, where real camera and mics are not involved in these tests, it's unlikely. A more likely suspect might be bug 1412394 which landed 10 days ago, as that made changes to MSG and shutdown. I'm ni?ing people involved with that bug.
Flags: needinfo?(jib) → needinfo?(apehrson)
Assignee | ||
Comment 46•7 years ago
|
||
Try with bug backed 1412394 out: https://treeherder.mozilla.org/#/jobs?repo=try&revision=3763225c80c7ff94bfc94c15cd0e58381e639a06 The time frames still don't seem to line up with any of these bugs landing, though.
Assignee | ||
Comment 47•7 years ago
|
||
Lets try some try bisecting... Try at b02047ad5ee7: https://treeherder.mozilla.org/#/jobs?repo=try&revision=a2cb004ad4a1fe1dde454b9924a34f87b52d06de Try at b6bed1b710c3: https://treeherder.mozilla.org/#/jobs?repo=try&revision=1489712f737d413ddc6e40c6c7ef39ba85b0678e Try at b705100d6ca8: https://treeherder.mozilla.org/#/jobs?repo=try&revision=7c432757efdf7a6d1fb98006daa0af074691bb81 Try at 4ce67352b2a9: https://treeherder.mozilla.org/#/jobs?repo=try&revision=16ee1c4704cf51644ace6fbcb521bce8a84d6b28 Try at cad9c9573579: https://treeherder.mozilla.org/#/jobs?repo=try&revision=8015704c2c312e2ef8418923a8cfe364e7b75166 Try at 5b33b070378a: https://treeherder.mozilla.org/#/jobs?repo=try&revision=c40c2360fce43cdb272cd61ae6023a46a0ecde64 Try at 3f6b9aaed8cd: https://treeherder.mozilla.org/#/jobs?repo=try&revision=1ec9a7791d971cf5c10319a472fe1d313c060172 Try at 7de1ab07869e: https://treeherder.mozilla.org/#/jobs?repo=try&revision=1dd2c44f96900faef9832f2da6296a1be7ab5ff4
Comment 48•7 years ago
|
||
Ben. Do you want me to run Process Manager and give you the data during the 6 seconds that it takes FX to startup? My bug report mentions that I saw under the Network data that for these 6 seconds it was executing some profiling task. This I thought might be Fx sending data to Mozilla.
Assignee | ||
Comment 49•7 years ago
|
||
(In reply to Gary [:streetwolf] from comment #48) > Ben. Do you want me to run Process Manager and give you the data during the > 6 seconds that it takes FX to startup? My bug report mentions that I saw > under the Network data that for these 6 seconds it was executing some > profiling task. This I thought might be Fx sending data to Mozilla. Thanks but the problems I'm running into are not really related to the actual delay your experienced. Don't worry, we'll get it sorted out.
Assignee | ||
Comment 50•7 years ago
|
||
(In reply to Ben Kelly [:bkelly] from comment #46) > Try with bug backed 1412394 out: > > https://treeherder.mozilla.org/#/ > jobs?repo=try&revision=3763225c80c7ff94bfc94c15cd0e58381e639a06 Backing out bug 1412394 did not help.
Assignee | ||
Comment 51•7 years ago
|
||
Results are still coming in, but so far its looking like: last good: 3f6b9aaed8cd first bad: 7de1ab07869e
Assignee | ||
Comment 52•7 years ago
|
||
e9c3a7b8062a: https://treeherder.mozilla.org/#/jobs?repo=try&revision=c64ac94725843589c770abed663d544b04287662 For those following along at home, we're looking for leaks in bc7 on linux64 debug and in bc2 on linux64-asan/win-debug 389962bc8c82: https://treeherder.mozilla.org/#/jobs?repo=try&revision=64fe5129134c328d61dc017e1868880959d81655 9cc79509e258: https://treeherder.mozilla.org/#/jobs?repo=try&revision=f326aa7a49625b2ff059491d61d49a164614ee09 dc40e5160744: https://treeherder.mozilla.org/#/jobs?repo=try&revision=1124634edeb46877cab5c3f2a438ba7948cd7f7a f1460a53233c: https://treeherder.mozilla.org/#/jobs?repo=try&revision=6e0a5d6fd998b0dc41c6bc4094efdea87359b5f1 058fc260a93b: https://treeherder.mozilla.org/#/jobs?repo=try&revision=d49c0958104ea731ab32451b2252287d6b40396b 4a91f7382c96: https://treeherder.mozilla.org/#/jobs?repo=try&revision=96fbbb61d75788ae72c2b0b0c7664f643af64a55 f7a11b900cd2: https://treeherder.mozilla.org/#/jobs?repo=try&revision=bca8c55659f95402df6b4dcc90269c0d9bbacd3f b0a56e8287da: https://treeherder.mozilla.org/#/jobs?repo=try&revision=59ed9ff9333ac75dac03a4ad75b6aa5a01e903a2 583311c68376: https://treeherder.mozilla.org/#/jobs?repo=try&revision=99ea95e15a84d54bb3c662513f996751ac616ca8
Updated•7 years ago
|
Flags: needinfo?(apehrson)
Assignee | ||
Comment 53•7 years ago
|
||
last good: b0a56e8287da first bad: 583311c68376 Only about 10 changesets in here. This one looks like a probably candidate: changeset: 394231:bbb02c1fccd6 user: Andrea Marchesini <amarchesini@mozilla.com> date: Wed Nov 29 09:40:16 2017 +0100 summary: Bug 1420419 - Postpone the removing of BlobURL for 5 seconds in order to allow the loading of them in a remote process, r=smaug
Assignee | ||
Comment 54•7 years ago
|
||
I'm going to do a trigger for each of these revisions on try. Andrea, in the meantime, do you think bug 1420419 could be causing this leak? Again, the problem is that there is a bug in the tree which makes us delay shutdown for 5 to 10 seconds. When I fix this shutdown delay I get a perma-leak in some tests. This change in the bisect range to hold stuff alive for 5 seconds seems suspicious. Does it listen for shutdown at all?
Flags: needinfo?(amarchesini)
Assignee | ||
Comment 55•7 years ago
|
||
a538864efb28: https://treeherder.mozilla.org/#/jobs?repo=try&revision=e131f81d0a3b26c54934377e764023af4968569c bbb02c1fccd6: https://treeherder.mozilla.org/#/jobs?repo=try&revision=689468ca58e8fd782bf2f566ba263d7c5390de3e 9e2680def2f9: https://treeherder.mozilla.org/#/jobs?repo=try&revision=b859a53f456d5a28cb5fe0845fb1494d0cb2e16f d0b0f4499790: https://treeherder.mozilla.org/#/jobs?repo=try&revision=73fa0386ae053f356d7fce5b1b8906e65f01de5d 649756a338c8: https://treeherder.mozilla.org/#/jobs?repo=try&revision=36b27d6706a5d255e118f4291fba2405aeed39ad 76bdc9a9451d: https://treeherder.mozilla.org/#/jobs?repo=try&revision=a8fa34eedaf5ce5f11df099e828198211e1f557f 583311c68376: https://treeherder.mozilla.org/#/jobs?repo=try&revision=828aaa553a21087fbb1ae8b337ab77066df57f12
Updated•7 years ago
|
Severity: normal → major
Has STR: --- → yes
status-firefox57:
--- → unaffected
status-firefox-esr52:
--- → unaffected
Keywords: regressionwindow-wanted → perf
Version: Trunk → 59 Branch
Assignee | ||
Comment 57•7 years ago
|
||
Yea, my last set of try pushes are pointing at bug 1420419 as the conclusive cause of the leak.
Assignee | ||
Comment 58•7 years ago
|
||
Try with patch from bug 1422314: https://treeherder.mozilla.org/#/jobs?repo=try&revision=9b4baf89ad1512023ad78c05a4cab535dd866285
Assignee | ||
Comment 59•7 years ago
|
||
Lets see if we can get some other platforms to run these tests: https://treeherder.mozilla.org/#/jobs?repo=try&revision=c05550bb0ac6814e8d902f509f857f579a62b478
Comment 60•7 years ago
|
||
My local mac build consistently takes >5s to shutdown. I got a shutdown profile (https://perfht.ml/2j2lqwM) that shows we are blocked for 5s at https://searchfox.org/mozilla-central/rev/7f45cb7cc0229398fc99849bdc150cb6462d6966/dom/workers/RuntimeService.cpp#2249 Not sure if this helps, only confirms what you already knew, or is an entirely different bug.
Assignee | ||
Comment 61•7 years ago
|
||
Please make sure to push this after bug 1422314.
Flags: needinfo?(amarchesini)
Keywords: checkin-needed
Comment 62•7 years ago
|
||
Pushed by bkelly@mozilla.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/7908b821ad3f P1 Make ClientManagerService track active ClientManagerParent actors. r=baku https://hg.mozilla.org/integration/mozilla-inbound/rev/f5a3054a4c38 P2 Eagerly shutdown ClientManagerService. r=baku a=aryx on CLOSED TREE
Keywords: checkin-needed
Comment 63•7 years ago
|
||
I'm running on the latest inbound which includes this patch as well as 1422314. Happy to say that the delay is gone. Kudos.
Comment 64•7 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/7908b821ad3f https://hg.mozilla.org/mozilla-central/rev/f5a3054a4c38
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla59
Reporter | ||
Comment 65•7 years ago
|
||
Thanks so much! Looks fixed for me in FF Nightly 59.0a1 (2017-12-03) (64-Bit) on macOS 10.12.6
Comment 66•7 years ago
|
||
Backed out 3 changesets (bug 1422314, bug 1420594) for failing xpcshell/test_ext_contentScripts_register.js on Android debug r=backout a=backout https://treeherder.mozilla.org/logviewer.html#?job_id=149165468&repo=mozilla-inbound&lineNumber=1874 https://hg.mozilla.org/mozilla-central/rev/195bb467e6cb5c8c5f5fb2858c0a55b2d0b9552d https://treeherder.mozilla.org/#/jobs?repo=mozilla-central&revision=0a559782a53a0d27424d3ec0c7f8a942ead597d7&selectedJob=149271085
Status: RESOLVED → REOPENED
status-firefox59:
fixed → ---
Resolution: FIXED → ---
Target Milestone: mozilla59 → ---
Assignee | ||
Comment 67•7 years ago
|
||
I'm kind of upset this was backed out for a single failing test when the backout creates the risk of more leaks being added.
Assignee | ||
Comment 68•7 years ago
|
||
I'm relanding with the test disabled on android for now.
Assignee | ||
Comment 69•7 years ago
|
||
Andrea gave me r+ for this in IRC.
Attachment #8934174 -
Flags: review+
Comment 70•7 years ago
|
||
Pushed by bkelly@mozilla.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/7ba9a363b3d2 P1 Make ClientManagerService track active ClientManagerParent actors. r=baku https://hg.mozilla.org/integration/mozilla-inbound/rev/a3e3a096629c P2 Eagerly shutdown ClientManagerService. r=baku https://hg.mozilla.org/integration/mozilla-inbound/rev/b0f2a1cfbd45 P3 Disable test_ext_contentScripts_register.js on android since it fails without the shutdown delay bug. r=baku
Assignee | ||
Comment 71•7 years ago
|
||
Please talk with me before backing out this bug. Its very critical that it stick since backing it out will create the opportunity for more erroneous code to be added. In the short time frame we had the extra shutdown delay we already had a late shutdown leak added and a problematic test added. We need to try to fix any new problems detected instead of backing this out. Thank you.
Comment 72•7 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/7ba9a363b3d2 https://hg.mozilla.org/mozilla-central/rev/a3e3a096629c https://hg.mozilla.org/mozilla-central/rev/b0f2a1cfbd45
Status: REOPENED → RESOLVED
Closed: 7 years ago → 7 years ago
status-firefox59:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla59
Updated•5 years ago
|
Component: DOM → DOM: Core & HTML
You need to log in
before you can comment on or make changes to this bug.
Description
•