Slashdot Mirror


Firefox Lorentz Keeps Plugin Crashes Under Control

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."

37 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.

    1. Re:How is this new? by mu22le · · Score: 2, Interesting

      I agree, my browser is already stable enough (all things considered). I wish there was a way to prevent flash from trashing 100% of my cpu for a stupid game.

    2. Re:How is this new? by TheRaven64 · · Score: 2, Insightful

      Same here. It's been happening since last night - around 14 hours ago, and it's quite irritating because it means that I can't see any of the replies to my posts. Without the ability to see - and reply to - replies, Slashdot becomes a one-shot discussion forum like OSNews or Digg. Please fix this soon!

      --
      I am TheRaven on Soylent News
    3. Re:How is this new? by hedwards · · Score: 2, Informative

      There already is, run FreeBSD. After all something can't crash that isn't available.

  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 Anonymous Coward · · Score: 2, Interesting

      We are working on that.

      https://wiki.mozilla.org/Plugins:PlatformIndependentNPAPI

      It will require the plugins to be re-written to not use any system APIs but here is work on that as well.

    3. 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...

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

      Well, why not just create two user accounts for your girlfriend and yourself respectively? That makes almost everything easier. Heck, you can even run them concurrently.

      --
      Colorless green Cthulhu waits dreaming furiously.
  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. Re:About time by ushering05401 · · Score: 2, Insightful

    We've known about plugin crashiness for a long time. We're just now going multi-process for this?

    Translating that to FOSS speak: We've known about plugin crashiness for a long time. This problem would never be fixed if it was up to me to fix it.

  6. Re:Ugh, another Chrome story by Anonymous Coward · · Score: 2, Informative

    Eh?

    Chrome sailed past 1.0 (on Windows) years ago. Look for the word "beta" in the About dialog (or anywhere else); you won't find it.

    Even on Linux and MacOS, it's going to be released as a stable in a couple of weeks, and even that distinction is mostly a formality. And they haven't used the word "beta" in over six months, either (and are also in-step with the version numbering used for Windows builds).

  7. 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.

    1. Re:Only as a side effect of being 32-bit by Anonymous Coward · · Score: 2, Informative

      Firefox plugins have been able to "voluntarily" use a subprocess for most activities for a long time - going back to netscape! They just need to, well, fork and exec a subprocess to do whatever they're doing. X11 even allows different processes to directly control subwindows as a design feature, though the subprocess could also talk back to the in-process segment of the plugin.

      However, initially for performance reasons and later when that became a realtive nonissue apparently just due to laziness (and probably partly due to highest-common-denominator effects - windows not having decent fork/exec and X11 not being its native gui layer...), flash and java in particular didn't. (Java relatively recently started doing so, though java was never the real problem in the first place - flash was).

      The difference here is that even if the plugin doesn't make its own subprocess, firefox lorentz is running the stuff in a separate process anyway. Which is a good thing given Adobe seems to be terminally incapable of writing a stable plugin for anything other than windows (and I have a notion that it only looks stable relative to windows stuff, linux and mac users have a much lower tolerance for random crashing).

  8. 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.

  9. 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 iammani · · Score: 2, Informative

      Mmmm are you sure not talking about the annoying Extension (extensions as in adblock, betterprivacy) updates? Because I have almost never be annoyed by any plugin installation/update (Except when I installed adobe flash on windows, when it wanted me to restart all browsers to start installation).

    2. 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'
    3. 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...
  10. 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.

    1. Re:Plugins, not extensions! by Protoslo · · Score: 2, Informative

      My earlier reading of the comments was unfair, the vast majority of posters seem quite clear on what a plugin is. Yay, slashdot!

    2. Re:Plugins, not extensions! by amorsen · · Score: 2, Funny

      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.

      There are much better products even on Windows which provide the same functionality as Acrobat Reader. E.g. the built-in Remote Desktop is quite ok these days, and TeamViewer is very nice.

      --
      Finally! A year of moderation! Ready for 2019?
    3. Re:Plugins, not extensions! by moonbender · · Score: 2, Funny

      Anything is better than running Acrobat Reader, even if it doesn't accomplish the same purpose.

      --
      Switch back to Slashdot's D1 system.
  11. Windows and Linux - not Mac by 93+Escort+Wagon · · Score: 2, Informative

    There appears to be a download for Mac available right at the same link - but from the FAQ:

    2. Why aren't multi-process plugins available on Mac?

    Mozilla is working on making multi-process plugins available on Mac. Because of architectural differences, the code is not ready for beta testing.

    --
    #DeleteChrome
  12. Why processes and not threads? by waztub · · Score: 2, Interesting

    Can anyone please explain to me why there's a need for completely new processes, as opposed to using threads?
    I'm curious as to what's the difference, and where the thread mechanism "fails" here.

    1. 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.

    2. 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).

  13. Re:Yay! by jez9999 · · Score: 2, Funny

    I think it's a combination of Flash! and Java but other things seem to take it out too.

    Did Yahoo! buy out Flash while I wasn't looking?

  14. What about resource usage by syousef · · Score: 2, Interesting

    Crashes are a hassle for sure, but if you're lucky and don't have an unstable plugin installed, you rarely crash. What I tend to see is runaway memory and CPU usage that forces me to close the browser and start again.

    --
    These posts express my own personal views, not those of my employer
  15. Chrome's stability is oversold by thaig · · Score: 2, Informative

    I'm using it now and I like it, but Chrome is not stable for me.

    It's problem is that it gets "stuck" in flash in such a way that nothing on my system can use the sound card.

    I can kill off all the tabs but there's still a chrome process running and until I kill that manually I can't play any music.

    I find this an incredible nuisance. Firefox has the same problem but when I kill it it's gone - no processes left behind.

    --
    This is all just my personal opinion.
  16. Chrome sandboxing by Mr.+Bad+Example · · Score: 2, Funny

    > Chrome sandboxes individual tabs, crashes of one tab does not affect the running of the rest of Chrome browser.

    Will Chrome also restart sentences in the event of comma splices?

  17. Will this completely prevent all crashes? Not now. by siglercm · · Score: 2, Informative

    Been running nightly 64-bit Firefox, automatically updated. I guess I got Lorentz a couple of nights ago, not sure when because I was traveling.

    Now no Flash instances run, they take 30 seconds or more to "initialize" before they crash, and the entire Lorentz-enabled Firefox browser crashed on me once. It just suddenly and unexpectedly disappeared. It's been a year or more since Firefox crashed on me.

    So at this point there are lots of bugs to shake out. Going back to vanilla 3.6.3 for the time being.

    --
    sigfault (core dumped)
  18. Re:Nice... but why by TheRaven64 · · Score: 2, Informative

    We've had it on FreeBSD for a while, and on x86-64 Linux too. It's been possible on most *NIX systems, but the motivation for doing it has been the lack of native plugins, not stability. Both FreeBSD and x86-64 Linux run 32-bit Linux plugins via nspluginwrapper, in a separate process. If you go to a site that crashes Flash, it just crashes another process. There's a little bit more overhead - an extra process instance, IPC between the plugin and browser instead of just function calls - so browsers on other platforms, with their focus on speed-at-all-costs have not bothered with it, until Google did and now everyone wants to.

    --
    I am TheRaven on Soylent News
  19. Re:Ugh, another Chrome story by Omestes · · Score: 2, Insightful

    The "beta" label has pretty much died. In Google-ese "beta" means a normal release, and when they hit the "1.0" and finally take of the beta tag, it pretty much means nothing.

    Have you been able to tell the difference between the beta of Gmail, and the full on release? I haven't.

    Now if you said this about the "dev channel", or Chromium daily, you would have a point. Though even being at "full-on release" status doesn't mean much, how often does Firefox update, and push bug patches, even at release status? The Mozilla team are tinkering with release versions about as much as Google is tinkering with their betas.

    If we're talking about stability, this isn't really an argument either. Chrome is about as stable as Firefox is currently. Both have nagging issues that don't seem to ever be fixed, though I haven't had Chrome or Chromium full-on crash yet, and I pretty much ditched Firefox's last full release because it didn't play well on either Win7 or Karmic (a crash a day is unacceptable).

    Also, you're talking about personal computing right, as opposed to business? And you're also talking about something as banal and inconsequential as a web browser, right? What's the worst that can happen (on a well protected OS), you loose your cookies or saved form data? We're not talking about running a server, or business app here, where you can loose data that actually matters, or worse, money.

    --
    A patriot must always be ready to defend his country against his government. -edward abbey