Can I close a firefox tab through the console?

There I was downloading a bunch of stuff from the Internet quite happily using Firefox built-in download manager when I decided to check code academy (a site that teaches you how to program in javascript, in a cool way - apparently).

So after playing with a few exercises I got to lesson 7 (item 4) which requires you to fill the conditions of a for loop to bring i (the loop variable) down to 0. What happened is that instead of writing the loop as for (i = 2; i >= 0; i--) which would trigger the inbuilt-mechanism that would take me to the next lesson, I "mistakenly" wrote is as for (i = 2; i >= 0; i++), making the loop go on forever causing Firefox to use 100% of the CPU, frizzing everything, and frustrating all my attempts to reload the page or close the tab.

Right now I have paused the process through kill -STOP <pid>, but I don't want to close Firefox because I'm downloading a bunch of stuff that can't be resumed, and I wonder if there's a way to close this tab through the command line. Maybe there's a way to list all firefox' threads and try to close them individually (worst case, I think GDB can assist me on this).

I'm currently using Mac OS X 10.7.2.

karlphillip

Posted 2012-01-08T19:34:39.680

Reputation: 971

3Switch to Chrome, perhaps? :) – Marvin Pinto – 2012-01-08T19:48:38.237

1I get the joke, haha, but that doesn't help me to achieve anything. – karlphillip – 2012-01-08T19:53:34.460

1In all seriousness though, I don't think you'll be able to do what you need. Firefox, unlike Chrome, opens all tabs in the same memory space which is why one misbehaving java/flash/whatever site will bring down all your browser sessions. Probably the same reason you can't kill one tab from the command line. – Marvin Pinto – 2012-01-08T20:00:17.283

1I see you're trying to close a firefox tab though the console. You should totally drop that and try jQuery. – Alex Coplan – 2012-01-08T20:26:05.383

But seriously, I don't think it's possible... http://stackoverflow.com/a/2076307/840973 - see the comments on the top answer

– Alex Coplan – 2012-01-08T20:31:21.320

@Marvin: "one misbehaving java/flash/whatever site will bring down all your browser sessions" ← actually, that's not quite right: since version 4, Firefox has a new file called plugin-container which launches a new process with the plugin, instead of embedding it in the main process. Usually you can actually kill this process without affecting the browser itself. The problem here is that Cool Academy doesn't actually use a plugin, but JS which is implemented by Firefox itself. – André Paramés – 2012-01-09T03:14:13.993

@karlphillip: if you have paused the process (and possibly even if you hadn't), the TCP connection to the server(s) has probably timed out already, so even if you get Firefox to work again, it might tell you that "filename could not be saved, because the source file could not be read". – André Paramés – 2012-01-09T03:18:46.323

@AndréParamés That's interesting, I wasn't aware of that. Does Firefox's container concept apply to tabs as well? If for example I had a (misbehaving) flash video playing in one tab which needed to be killed. After killing it, would it also affect any other tabs that I may have had open with flash videos (again, silly example but bare with me). I ask because in my understanding of how Chrome works, each tab is somehow sandboxed and killing one (be it directly or via process explorer/activity monitor), will certainly not affect any other. – Marvin Pinto – 2012-01-09T03:31:26.787

@Marvin: No, a single plugin-container will be launched per plugin, regardless of on how many tabs it is used. So if a Flash video is unresponsive, killing the process will kill all other Flash components in all tabs. It doesn't kill the whole tab, though, just the Flash part. – André Paramés – 2012-01-09T19:18:17.620

Answers

I did the same on Codecademy. Filled out something wrong and that resulted in an infinite loop, it seems like Codecademy isn't written to prevent such bad behavior so it gets elevated to the browser. In my case the browser just catches this and asks after a while to stop the script. I find it weird that this does not appear to be happening in your case, hence I would suggest you to upgrade Firefox after solving this so that this kind of condition can't occur again.

I'm afraid there is no way but finding a genious process management tool or attaching a debugger like gdb, this can become very tricky if you don't have any debugging information though. Just look for the thread that is somewhere in the Javascript execution routines. If you have no debug information and no dynamic libraries I guess it will be somewhere in xul.so which could be about any tab.

If you somehow figure out what the download thread is, you could attempt to freeze the other threads one by one to figure out which one is the actual tab. In the worst case freezing threads doesn't help, as the thread might be holding a lock that the other threads are waiting for. In that case you'd better just kill the process and start over with the downloads. Perhaps consider to huge downloads in a different way than with your browser, if possible...

Tamara Wijsman

Posted 2012-01-08T19:34:39.680

Reputation: 54 163

Just click the close-tab icon and wait, as soon as it gets CPU time it will shut it down. Or press ctrl-w (once) while the window is active, and wait.

Mattias Ahnberg

Posted 2012-01-08T19:34:39.680

Reputation: 938

I have done that, frenetically, for the past 30 min. It's no good. – karlphillip – 2012-01-08T19:42:12.787

Are you on Windows? If you are, you could (conceivably) use ProcessExplorer to zero in on the misbehaving thread/s and kill it/them - just look for constant CPU/memory consumption and JavaScript function names. But be very careful - this should be precision surgery.

On other OSs, you could use a debugger to achieve the same - but it's quite a hassle.

Traveling Tech Guy

Posted 2012-01-08T19:34:39.680

Reputation: 8 743

I'm on Mac OS X as I said before. I'm investigating if GDB can do the job. – karlphillip – 2012-01-08T20:09:30.003

It probably can. You could probably use Activity Monitor to help pinpoint the threads. Sadly, if I recall correctly (don't have it front of me) it will only allow killing a process - not a thread. But maybe it can save you GDB drilldowns – Traveling Tech Guy – 2012-01-08T20:15:27.917