Slashdot Mirror

← Back to Stories (view on slashdot.org)

Firefox Lorentz Keeps Plugin Crashes Under Control

Posted by timothy on from the pleasant-fantasy dept.

pastababa writes "A beta of the Firefox Lorentz project is now available for download and public testing. Eming reports Firefox 'Lorentz' provides uninterrupted browsing for Windows and Linux users when there is a crash in plugins. Plugins run in a separate process from the browser. If a plugin crashes it will not crash the browser, and unresponsive plugins are automatically restarted. The process-isolation feature has been in Google's Chrome from the beginning. Chrome sandboxes individual tabs, and the crash of one tab does not affect the running of the rest of Chrome browser. Firefox currently isolates only Adobe Flash, Apple Quicktime, and Microsoft Silverlight, but will eventually isolate all plugins running on a page. Mozilla encourages users to test Firefox 'Lorentz' on their favorite websites. Users who install Firefox 'Lorentz' will eventually be automatically updated to a future version of Firefox 3.6 in which this feature is included."

16 of 115 comments (clear)

  1. How is this new? by CRCulver · · Score: 3, Interesting

    Versions of Gnash have frequently segfaulted on my Linux box (the segfault is reported by dmesg), yet I've never had a browser crash because of it. I had thought that plugins were already isolated enough from the application as a whole.

  2. This is all fine and dandy, by gzipped_tar · · Score: 5, Insightful

    but can it be extended so that plugins are not only run in their separate processes, but separate SELinux sandboxes as well?

    --
    Colorless green Cthulhu waits dreaming furiously.
    1. Re:This is all fine and dandy, by mrsteveman1 · · Score: 5, Funny

      I'd prefer they run on a separate machine. Someone else's machine in fact.

    2. Re:This is all fine and dandy, by the_womble · · Score: 3, Insightful

      [quote]Even though X haters have been screaming for years that network transparency needs to go.[/quote]

      Largely because they do not realise how useful it can be...

  3. Will this completely prevent all crashes? by uvajed_ekil · · Score: 3, Informative

    Hmm, Google Chrome already handles plugins this way, but one flash-heavy site I know delivers a lot of streaming video and absolutely will crash either Firefox or Chrome in linux (I use Mint, mainly) without fail, if given enough time, Gnome or KDE. Crash as in the entire browser becomes unresponsive and must force-close. After it did this to Firefox a few times I tried Chrome, with the same result. Everything will be fine for a few minutes, sometimes up to an hour or so, then the whole browser will die. Haven't tried IE, tried Firefox with Windows 7 and had the same thing happen. I will certainly look into anything that prevents crashes for Firefox, since I strongly prefer it to every other browser I've tried, since most of the time it works perfectly.

    --
    This is a hacked account, for which the owner can not be held responsible.
    1. Re:Will this completely prevent all crashes? by Anonymous Coward · · Score: 3, Informative

      If you see the same problems in a development Firefox build, please file a bug report against Core::Plugins at bugzilla.mozilla.org. We'd love to figure out what's wrong and fix it.

  4. Using it now by flyingfsck · · Score: 3, Insightful

    Let's see how it goes. The auto-restart of plugins should be good, but could also cause a plugin DOS.

    --
    Excuse me, but please get off my Pennisetum Clandestinum, eh!
    1. Re:Using it now by The+MAZZTer · · Score: 5, Informative

      I didn't think it autorestarted plugins. They even provided a reason (probably the same reason Google did it)... current webpages will not expect plugins to restart. And because it's possible for Flash to make JS calls etc this could lead to side effects and page breaking, I think they thought it was just best to reload the page so JS restarts too. Of course I read this on a blog a few weeks back, they could have changed their minds?

  5. Only as a side effect of being 32-bit by pavon · · Score: 4, Interesting

    No, this has not been the normal plugin architecture. When Linux moved to 64-bit, firefox was ported to 64-bit but all of the proprietary plugins were still 32-bit. The solution to this problem was to create nspluginwrapper which would run the apps in a separate process. It had some bugs of it's own, wasn't always reliable about letting you restart crashed plugins, and has itself crashed the browser on me, but it largely prevented plugins from crashing the browser as a side effect.

    Older 32-bit versions of firefox on linux, and all versions on windows did not have this capability.

  6. Re:About time by zero-point-infinity · · Score: 3, Informative

    Konqueror has run flash (and more generally nsplugins) in a separate process since before Chrome was even a rumour. I used to run Konqueror as my primary browser and when I stopped using it I was surprised to discover that other browsers didn't run flash as a separate process.

  7. No restart on plugin installtion/update? by deek · · Score: 5, Interesting

    Does this mean that, when "Lorentz" covers all plugins, we can install and update plugins without having to restart Firefox?

    That would be a worthwhile feature. It's annoying having to restart the browser for any plugin changes.

    1. Re:No restart on plugin installtion/update? by xtracto · · Score: 3, Interesting

      Ah yeah, that is one of the most irritating things I hate on firefox. Why would I have to restart the web browser after installing an extension like scrapbook? this is from the people who whined that you have to restart Windows for any reason...

      What I would really like is an "extension profiler", that is, a program that let you check exact statistics of resources used by the different Firefox extensions. This way you could see which is the extension that is taking more memory or time and it may be a good tool to debug extensions when developing them.

      --
      Ubuntu is an African word meaning 'I can't configure Debian'
    2. Re:No restart on plugin installtion/update? by X0563511 · · Score: 3, Informative

      Plugins are not extensions.

      --
      For large sets, this will be our guide even unto death, for the LORD will work for each type of data it is applied to...
  8. Plugins, not extensions! by Protoslo · · Score: 3, Informative

    Firefox currently isolate [sic] only Adobe Flash, Apple Quicktime and Microsoft Silverlight, but will eventually isolate all plugins running on a page.

    The quote emphasizes that Lorentz affects only plugins, not extensions, a distinction that seems to be escaping many posters.

    I've had flash behave pretty screwily short of crashing, so this might be nicer if it included a mechanism to manually stop & restart plugins. Perhaps it will expose API allowing other add-ons to do so.

    The plugin that gives me by far the most trouble (on Windows) is Adobe Acrobat Reader. I can already restart that (by killing the process) without crashing firefox.

  9. Re:Why processes and not threads? by Cobra_666 · · Score: 5, Informative

    Separate address spaces. When a thread crashes, the whole process goes down. If separate process dies, the browser should still be intact.

  10. Re:Why processes and not threads? by kangsterizer · · Score: 3, Informative

    yeah that's also why chrome uses so much memory, and also, processes are be nature slightly slower to communicate since you can't just lock and access the memory. In practice however its peanuts, and on Linux its pretty much just as good.

    anyways, using subprocesses for plugins makes complete sense. using them for tabs etc are just a way to work around the browser's instability. Rather have quick threads and non buggy code, than people just thinking a plugin went wrong while really, the browser is at fault. (Sure, you only lose the tab in that case, but still).