Closed Bug 1258515 Opened 8 years ago Closed 8 years ago

After Firefox update, Macbook won't shutdown

Categories

(Firefox :: General, defect)

Product:
Firefox
Component:
General
Version:
45 Branch
Platform:
Unspecified
macOS
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED WORKSFORME
Tracking Flags:
Tracking Status
firefox45 + wontfix
firefox46 + wontfix
firefox47 + wontfix
firefox48 + wontfix

People

(Reporter: morganbob, Unassigned)

References

Details

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Firefox/45.0
Build ID: 20160315153207

Steps to reproduce:

The first time running of all 5 FF updates since Sept 2015 caused my MBP to fail shutdown.  Two images of FF show after shutdown fails, neither of which can be killed by normal Forced Quit procedures.  


Actual results:

Only way to shutdown is long hold-down of power button.  If newly installed FF is not started, then shutdown is OK, but the next day shutdown fails.  The next system start after the hard shutdown asks whether whether to restart running tasks and I say "No", then FF works great until the next update is applied.


Expected results:

A new version of FF should have no effect on computer shutdown.

Computer is Macbook Pro Model 1398 running OS X 10.13.3
I was just about to file a bug on this issue after having seen it on Facebook and in the SUMO forums.

Facebook post (must be logged in to see):
https://www.facebook.com/Firefox/posts/10156536997655022?comment_id=10156689102855022
"Firefox is now frequently preventing my Macbook from shutting down and I can't force quit Firefox either. It never did this before."

Firefox doesn't close correctly and stops mac from restarting:
https://support.mozilla.org/en-US/questions/1115622
(OS X El Capitan 10.11.14)

Another thread mentioned this has been going on for a few versions now:
Updates always create another icon in the dock, and the Mac won't shut down
https://support.mozilla.org/en-US/questions/1115040
(OS X El Capitan 10.11.3)

I'm tagging all cases here:
https://support.mozilla.org/en-US/questions/firefox?tagged=macshutdown

Input reports:
https://input.mozilla.org/en-US/?q=shutdown&date_end=2016-03-24&date_start=2016-02-01&platform=OS%20X
https://input.mozilla.org/en-US/dashboard/response/5840859
https://input.mozilla.org/en-US/dashboard/response/5850126
https://input.mozilla.org/en-US/dashboard/response/5826163
https://input.mozilla.org/en-US/dashboard/response/5821285
https://input.mozilla.org/en-US/dashboard/response/5815938

This bug appears to date back all the way to Fx 43 (Dec 2015):
https://input.mozilla.org/en-US/dashboard/response/5724343

This sounds like a very severe regression to me so I'm marking this as critical. Of all the problems I've witnessed in my ~11 years of Firefox support, this is the most insane and embarrassing bug I've ever seen. That it can't be force quit in the Activity Monitor & the OS can't shutdown and kill the process blows my mind.

Tyler & Liz, would you be able to prioritize this bug and get the word out to the devs? I have no idea which devs specialize in mac shutdown code. But since the updater is mentioned, Rob Strong comes to mind. Needinfo'ing him.
Severity: normal → critical
Status: UNCONFIRMED → NEW
Component: Untriaged → Installer
Ever confirmed: true
Flags: needinfo?(robert.strong.bugs)
Flags: needinfo?(lhenry)
OS: Unspecified → Mac OS X
Quite certain that neither the installer or the updater is preventing the shutdown... moving over to Firefox -> General for now.

needinfoing bsmedberg and spohl to get eyes on this
Component: Installer → General
Flags: needinfo?(spohl.mozilla.bugs)
Flags: needinfo?(robert.strong.bugs)
Flags: needinfo?(benjamin)
Actually, it might be the updater and spohl should be able to check if it is
Does running the following from Terminal recover the situation and can the system be shut down?

sudo killall launchservicesd
sudo killall Dock
Flags: needinfo?(spohl.mozilla.bugs)
Yes, according to Mattowski from the 1st post in this thread:
https://support.mozilla.org/en-US/questions/1115622

"However some bright spark has deduced that you can do the following (provided you hadn't already tried to restart):

Open the terminal window and perform the following commands:
sudo killall launchservicesd sudo killall Dock"
Flags: needinfo?(spohl.mozilla.bugs)
This workaround came to mind due to bugs such as bug 1242888 and bug 1250901. I can't say with certainty that they are all caused by the same underlying issue.

If this is at all related to restarting Firefox after an update (typically the reason why a second icon is shown in the Dock), it may be due to our use of posix_spawnp instead of |NSTask launchedTaskWithLaunchPath| to relaunch Firefox after an update. We're moving to |NSTask launchedTaskWithLaunchPath| in bug 394984 for unrelated reasons. I wonder if we could split this change out and test on an affected system, or if this is profile-specific, if we could get a copy of an affected profile.
Flags: needinfo?(spohl.mozilla.bugs)
Is this for 45.0.1 only? Happening also on beta, aurora, nightly?
Flags: needinfo?(lhenry)
If we can find the cause, we can try to do the world's fastest dot release. Sylvestre is on PTO so please needinfo to me and ritu. Many people are off tomorrow as it is a holiday in various countries. So we will need to pull in developers for testing, landing patches, etc.
A note I didn't see this issue on beta 4 on my Mac with OSX 10.11.4, with an old profile or a new profile.
So, sanity check -- do we have any reason to believe this is a new issue or widespread?

So far I count 9 people recently affected -- this bug + (from comment 2) 1 Facebook post + 2 SUMO topics covering 6 people + 1 Input feedback since release on 3/8. Of course that's not an absolute count, but relative to the number of people reporting other issues it doesn't seem alarming.

For recent history, Noah's Input query shows:
 *  1 report  during the 45 cycle (3/8 to now, and we're nearly halfway thru the cycle)
 * 14 reports during the 44 cycle (1/26 - 3/8)
 * 14 reports during the 43 cycle (12/15 - 1/26)
 *  6 reports during the 42 cycle (11/3 - 12/15)
 *  2 reports during the 41 cycle (9/22 - 11/3) [Well, no data before 9/27]

Given that we don't know the actual cause and it's been an fairly low-rate ongoing issue, I'm not sure there's any fire here or immediate action to take. Although it's certainly an issue to continue investigating.
(In reply to Liz Henry (:lizzard) (needinfo? me) from comment #7)
> Is this for 45.0.1 only? Happening also on beta, aurora, nightly?
From what I've been able to dig up, it looks like this bug started with Fx 43 and that 42 was unaffected. Thanks to the feedback I found on Input, I was able to paint that timeline.

https://input.mozilla.org/en-US/?q=shutdown&platform=OS+X&date_end=2016-03-24&date_start=2015-11-21
https://input.mozilla.org/en-US/?q=shutdown&platform=OS+X&date_end=2016-03-24&date_start=2015-11-21&page=2
^ Since 12-4-15, 24 confirmed cases of Firefox 43-45 breaking El Capitan's shutdown & 2 reports for 10.6.8 (Snow Leopard).

First reported on a Fx 43 beta build (Dec 4, 2015):
https://input.mozilla.org/en-US/dashboard/response/5724343

Thanks for the quick replies Rob, Stephen and Liz! I realize it is the holidays for some people so I understand if this has to sit until Monday or Tuesday.

I can't say if this is happening to every El Capitan user but I'm seeing enough reports of it to be concerned. And this issue has languished since December so 45.0.1 can't be responsible for this. As long as we keep some priority on getting this fixed, I'm happy.
(In reply to Justin Dolske [:Dolske] from comment #10)
> Given that we don't know the actual cause and it's been an fairly low-rate
> ongoing issue, I'm not sure there's any fire here or immediate action to
> take. Although it's certainly an issue to continue investigating.
Thanks for doing those stats too Dolske! What I gather is that many more users could be experiencing this on update, finally figure out they need to hold down the power button for 5 seconds to force a shutdown or pull the battery/plug, then test opening and closing Firefox on the next startup. If it exits without hanging, they chalk it up to being a one time glitch and don't report it.

So yeah, I'm in agreement w/ Dolske. Nothing we can do to fix this immediately by this weekend but wanted to keep everyone alerted of this. It's a pretty nasty bug to have encounter *everytime* you perform an update and we already know how much our users hate updating. This makes them hate it *even more*. Imagine another 43.x.x dot release series. :P
OK, thanks, I would rather have overreacted than to let a problem keep snowballing. Let's turn updates back on.
Let's go ahead and track this across all current versions.
status-firefox46: ? → affected
status-firefox47: ? → affected
status-firefox48: ? → affected
tracking-firefox46: --- → +
tracking-firefox47: --- → +
tracking-firefox48: --- → +
I doubt a non-software person could figure how to report a problem.  Only after the 5th failure did I bother to spend enough time to figure out how to report the problem.

I'd guess the problem is in whatever changed in the "first-time" image startup code that took place in December.

If you are unable to recreate the problem in your lab, I'd be happy to install an update and work with you to gather information.
Bob, 
I wonder what happens if you install Nightly?  That will be a separate install and updates every day. Do you see the issue on that.
info https://developer.mozilla.org/Firefox -> downloads https://nightly.mozilla.org/

You may wish to use multiple profiles, and possibly clone the  profile used day to day for the Release to test with Nightly. Or you may be able to reproduce with a clean new profile. See https://developer.mozilla.org/Firefox/Multiple_profiles

I note Stephen A Pohl [:spohl] (PTO 3/25) from comment #6 asked
> ... or if this is profile-specific, if we
> could get a copy of an affected profile. ...
You will not wish to post a copy of a profile in a public bug, but you may be willing to email a copy to a named developer.

If you are able to reproduce I also wonder if you may be able to try to get a regression range for this with the aid of the mozregression tool http://mozilla.github.io/mozregression/
Someone on Sumo has reported being able to reproduce a similar problem
https://support.mozilla.org/en-US/questions/1115089#answer-860316 
>It turns out that I can recreate the problem.
>I normally run Firefox in Private Browsing mode, 
>but needed to switch to a normal window for one website.  
>Since I couldn't figure out how to start up a non-private window, 
>I reset the preferences (which forced a Firefox restart), 
>and i ended up with 2 instances of Firefox on my dock - my 'normal' one and a 2nd temporary one.
> 
>After I was done, Firefox would not shut down.  
> After holding the power button on my MBP to force a shutdown, 
>the restart came up with only one Firefox icon on the dock (as expected), and I was able to proceed.
I downloaded and ran Nightly and it showed "Nightly" in top bar and "About Nightly showed 48.0a1...  I didn't do anything regarding Preferences.  I went to Apple and Yahoo websites, then did my normal shutdown and restart without problem.  Does this mean the problem is corrected in the Beta versions?

After restart I can't find any trace of "Nightly", only the .DMG file that created it.
It is possible the problem is corrected in pre Release versions. It is also possible the problem relates to the profile you used. Part of the problem is trying to reproduce the issue you see. We see enough reports to know it is a real issue, but I don't think we are sure yet who is affected or why. I am not a developer or a Mac user. 

Right now may be a holiday in some countries so you may need to wait a while for people to get back to you.  This information from a respected third party site may help with sorting out Nightly 
http://kb.mozillazine.org/Testing_pre-release_versions#Installing_multiple_versions
Apparently the issue may not be Firefox specific. AliceWyman in a Sumo discussion pointed to an Apple discussion mentioning "Adobe Reader, Path Finder ... and Text Edit"
https://support.mozilla.org/kb/forum-response-firefox-45-mac-wont-shut-down-bug-1/discuss/6572#post-13480  -> "Firefox won't Force Quit?" https://discussions.apple.com/message/29584366#29584366
Hi guys, 

This issue was also mentioned a while ago on an older issue (bug 1230607 at comment nr 12). I did some diggings on an Apple discussion thread opened related to this problem (https://discussions.apple.com/thread/7307276?start=0&tstart=0. Some users there mentioned that they managed to fix this by removing the MacUpdate Desktop software. Maybe there's a conflict between Firefox and the Apple software that keeps the process locked. Other mentioned that they resolved this by disabling hardware acceleration.

I haven't checked this yet but I'll give a try in the next days. Will post an update if I can reproduce this.
Looks like this also happens when using the terminal and the profile manager per bug 1230607.
Although I'm not working on this bug directly, we are going to land a replacement for posix_spawnp to restart Firefox in bug 394984. Since reports mention updates (which restart Firefox via posix_spawnp) we're hoping that this change will improve/fix this issue.
Flags: needinfo?(benjamin)
OK, this sounds like a longstanding and intermittent issue -- at least, not happening for every mac user on update.   Wontfix for 46.
status-firefox45: affected → wontfix
status-firefox46: affected → wontfix
Yesterday I've upgraded another laptop to El Capitan and same problem started to happen.

It doesn't happen only on updates. When firefox crashes it also happens and most of times if I close it (by pressing cmd+q) it also happens. It's not intermittent once the computer is affected. Reinstalling doesn't fix it either.

I must say that this is a very annoying bug.
After talking to Sergio, who has seen the same bug in two other machines from other people, one theory is that this might be triggered more easily by the Yosemite -> El Capitan upgrade, whereas in a clean install the problem doesn't happen.

Also, it appears that it is a OSX bug that is more easily triggered by some Firefox code. And it's not a recent regression because the bug manifests itself even with old versions of Firefox.

Can we get someone from QA to try a couple of Yosemite -> El Capitan upgrades, where Fx was previously installed, and see if they can reproduce the problem?

It's a pretty severe bug when it hits the user: makes it impossible to re-open Firefox after it's been closed, and impossible to shut down the OS cleanly.
Keywords: qawanted
Still exists in 45.0.2 install.  Before doing download I quit all apps except FF.  After download the existing  FF worked OK.  Quit existing FF OK.  Clicked FF icon to start new version.  Cmd-tab now shows two FF icons and once there are two icons FF can never be closed.

Whatever is being done in the "first time only" code is what leads to the two icons and no shutdown problem.

For me, this is a minor annoyance as it wastes less than 5 minutes per FF update.
What is happening to me: https://www.youtube.com/watch?v=v3r7zgSX6Cs

Both times I've closed Firefox using cmd+q.

I'm available and willing to help if you want to do further investigations in my two machines affected.
This has been happening for me for quite some time.  I did a Yosemite to El Capitan upgrade as mentioned above. I cannot use Firefox at all.  Every time I start Firefox it leaves a dead ghost process running and I cannot restart Firefox or shut down my Mac.  It renders Firefox completely useless to me.  Let me know if I can provide any diagnostic information to help track this down.
Just got a message from Apple asking to stop the "Rapport Trusteer Endpoint Protection" service, restart Firefox and try to use reproduce the bug again. I did it and it "solved" my problem.

The Rapport service is an IBM software used by hundreds of banks around the world including Banco do Brasil (the major bank we have here).

I'm gonna confirm with other users in the Apple forum to see if they also have this service running.

I can also confirm that Rapport service works fine with Google Chrome.
I do have Rapport running in my browser.  When I get the next Firefox update, I will stop Rapport before starting the update and report back with the results.
If Rapport was running when you started your browser that won't work. You should stop rapport, restart your browser and then do the update.
Stopping Rapport, quitting FF, restarting FF, then doing the update, solved the "fail to shutdown" problem.

But, after restarting FF, the Rapport icon no longer shows in the browser address bar. The direct interface to Rapport says it is running.  Icon shows OK in the Safari address bar.  A system Shut Down/Restart doesn't help.
Hi florin, based on comment #27, can we get some QA help?
Flags: needinfo?(florin.mezei)
(In reply to Gerry Chang [:gchang] from comment #35)
> Hi florin, based on comment #27, can we get some QA help?

Latest comments in this bug and on the https://discussions.apple.com/thread/7307276?start=30&tstart=0 thread all point at this issue happening when IBM Security Trusteer Endpoint Protection (Rapport) for Mac is installed on OS X El Capitan 10.11 (https://www.trusteer.com/en/support/mac-install-instructions), and users try the following:
1. Update Firefox (e.g. 44->45, 45->46)
2. Quit Firefox (cmd+q)
3. Start firefox again (click Firefox icon)

Results: two Firefox icons now show, and Mac would no longer shutdown (blocked by Firefox being open)

Andrei - could we give this a try on our Mac OS X 10.11 machines when we have some time?

Felipe - what sort of debugging would be helpful for you here? Also I think we've had some previous issues with Trusteer on Windows recently, so those bugs may provide some additional info

All other reporters - are any of you still willing to help out with debugging if needed?

Note: I don't think we need to try the scenario with upgrade to El Capitan, since the apple thread suggests that this is happening on clean OS X 10.11 installs as well.
Flags: needinfo?(florin.mezei)
Flags: needinfo?(felipc)
Flags: needinfo?(andrei.vaida)
Hi Florin, I don't think more QA efforts are necessary here. Now that we've found what's causing it, what we really need are two things:

 - find a contact within IBM's Rapport Trusteer team and report the bug to them and work together on fixing it
 - some of our OSX developers try to investigate if a workaround is possible to avoid the bug


We really need to contact someone because this is a serious bug..
Flags: needinfo?(felipc)
(In reply to :Felipe Gomes (needinfo me!) from comment #37)
>  - find a contact within IBM's Rapport Trusteer team and report the bug to
> them and work together on fixing it
>
> We really need to contact someone because this is a serious bug..

Mike, do you have any remaining contacts which could help us here?
Flags: needinfo?(mozilla)
Checking...

The company that wrote this is based in Israel, so there might be other folks that have contacts. I would suggest other folks go to LinkedIn and search on Trusteer and see if they have any connections.
Flags: needinfo?(mozilla)
Holding off on any further investigation here, based on Comment 37. Felipe, Gerry - feel free to ni? me again if there's progress made on this bug.
Flags: needinfo?(andrei.vaida)
Keywords: qawanted
From the Trusteer team:

Kindly note that I have taken ownership of this case and was able to reproduce the described issue.

I am escalating this investigation to our 3rd Tier Support team. You will be contacted as soon as additional information becomes available.

Thank you for bringing this issue to our attention and for your patience with this matter.
(In reply to Stephen A Pohl [:spohl] from comment #24)
> Although I'm not working on this bug directly, we are going to land a
> replacement for posix_spawnp to restart Firefox in bug 394984. Since reports
> mention updates (which restart Firefox via posix_spawnp) we're hoping that
> this change will improve/fix this issue.

Now that bug 394984 landed on nightly, could someone try to reproduce this issue with nightly? It would be great to know whether or not bug 394984 improved things here.
The problem still reproducible on today's build (20160601061753).
From Trusteer support:

> In order to avoid any inconvenience for the MAC Mozilla Firefox users, I would like to inform you that as a temporary solution we have removed the Trusteer Rapport injection from all versions of MAC Firefox web browser. This means that Trusteer Rapport should have no impact on MAC Firefox users in any way.
This temporary solution has been already released to all end users.

> Kindly note that we are doing our best to release a new Rapport version to permanently resolve this issue as soon as we can.
Shipping 48 with this bug, stop tracking, please renominate for tracking when ready.
status-firefox47: affected → wontfix
status-firefox48: affected → wontfix
SOLVED--- As original reporter of this problem I consider it solved when using FF 48.0.1 and Trusteer 3.6.1609.22.  

Trusteer was running when updating and restarting 48.0.1, system was shutdown and restarted without any problem.  Also, Trusteer shows as running after restart.
Thanks for getting back to us.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → WORKSFORME
I'm experiencing this after updating to 48.0.2
(In reply to leotreasure from comment #48)
> I'm experiencing this after updating to 48.0.2

Please file a new bug with detailed steps to reproduce and let us know if you have Trusteer installed. Thanks!
The fix to the original problem took a slight step backwards.  

After update from 48.0.1 to 49.0 and restarting FF only a single FF in dock, unlike original problem.  But, Trusteer icon not showing in URL, but Preferences says it IS running.  Started Safari and it does show Trusteer in URL.  Successfully shutdown and restarted MBP.  Did a manual stop of Trusteer and as expected Safari has no Trusteer icon in URL. Did a manual start of Trusteer and now neither FF or Safari shows the Trusteer icon in the URL.  I got tired of messing with it for the day.

The following day when I fired-up the system, everything was perfect, the Trusteer URL was back for both FF and Safari.
Hi,
On macOS Sierra, impossible to shutdown from a session (impossible to quit safari, FF, microsoft word) after updating Firefox 50.0.2 while possible to shutdown from another session. 
I don't know where to find this Trusteer and would appreciate help to fix the problem.
Thanks
You need to log in before you can comment on or make changes to this bug.