Skip to main content

Stabilizing Firefox for beta quality plugins (Flash)

Using the recent Adobe Flash plugin in Firefox is a two edged sword. On one hand, it gives you the never ending joy of useless YouTube videos, but on the other hand it crashes your browser every 24h on average (only if you are also using Flashblocker which reduces flash content activation by 80%, namely all the annoying ads).

Presumably because of Flash, nspluginwrapper was invented to wrap up software of vendors that are incapable of producing 64-bit version of their product. nspluginwrapper works by providing a proxy to Firefox that acts as regular plugin, but actually spawns off a separate process that runs in 32-bit mode that links in the shared object of the plugin. We can use this construction to remove Flash from the intimate dlopen embracement of Firefox and move all negative side effects of beta quality software into a subprocess. The following trick works for all 32-bit browsers, whether the rest of your distro is amd64 based or native i386. If you are using a 64-bit browser, it's likely that you know nspluginwrapper anyway, so this blog entry is about 32-bit to 32-bit.

Grab a copy nspluginwrapper (at least Untar it. Compile it under an i386 environment. If you don't have this at your disposal, here is it precompiled from my local Gentoo installation: nspluginwrapper- This is compiled for the amd64 arch layout of Gentoo. Under native i386, just create a link from lib32 to lib in /usr.

Now grab a copy of Drop it into a directory that is not part of your default Firefox plugin path and that does not contain the substring 'netscape' in its absolute path. So, /opt/netscape/plugins/ is wrong twice, /usr/lib32/nsbrowser/plugins is wrong only with respect to the default plugin path, and /usr/lib32/nsbrowser/wrapped-plugins/ is correct.

The reason why the path must not contain 'netscape' is that presumes its part of a netscape installation when it sees 'netscape' in its path and malfunctions for Flash movies as on YouTube and Google Video under nspluginwrapper and Opera.

Invoke /usr/lib32/nspluginwrapper/i386/linux/npconfig -i /usr/lib32/nsbrowser/wrapped-plugins/ As super user, this creates in /usr/lib32/nsbrowser/plugins. Invoking this as normal user drops this file into ~/.mozilla/plugins. You are now read to go with your new shielded Firefox. Check that it contains a Section 'Shockwave Flash' under about:plugins referring to the file. If it refers to directly, you have a copy of laying around in a plugin path.

Flash might still cause lock ups in this setting. I presume Flash is getting stuck in an endless loop keeping Firefox busy even through the proxy. However, when that happens just kill the nspluginwrapper subprocess called npviewer. After that Firefox should refresh and you can just hit reload on Flash sites (instead of killing firefox and reloading all websites). Good luck.


Popular posts from this blog

Liskell standalone

Some time has passed since I last blogged about Liskell. It is not dead nor have I changed my mind that Haskell needs a proper meta-programming facility not to mention a better syntax.Liskell was a branch of GHC once. Now it sits on top of the GHC API, or I should rather say sneaks behind its back as it creates its own API as the original one is not suitable for the stunts I'm interested in. If Liskell sticks with GHC as its soil, I will definitely send patches upstream to refine the GHC API in the areas where it needs more flexibility for Liskell. However for the moment, my main target was to get something out that compiles with a stable version of GHC.You can grab it with the usual: darcs get This version has been tested with ghc 6.10.1 and should install like: ./Setup.lhs configure ./Setup.lhs build ./Setup.lhs install cd LskPrelude make install-inplace Optionally you can run make tests in the testsuite subdirectory. Thanks to community.haskell…

XMonad GridSelect

Personally, I not just need a window manager, I need a focus manager. I tend to think of windows as TODO items, and as there are many TODOs in life there are many windows on my workspaces. Usually a fraction of that can't be closed or worked on immediately, so they linger around on my desktop, cluttering my workspace.I used to use the Tabbed layout. But Tabbed isn't the answer when you are a guy who reports bugs such as "XMonad 0.6 with Tabbed dies when firefox-session-restore slams 40 windows at once on the desktop". In other words, I use a lot of windows. The workspaces concept isn't particularly useful to me either. My mind just doesn't work with mental boxes. So the result is, that I have too few workspaces with too much windows on them, so that Tabbed has trouble displaying useful window titles, and navigating through them is slow and cumbersome (mostly because tab switching generates a lot of useless X Expose events).GridSelect is my answer to that. It…

Removing CHS based access from windows boot loaders

Recently, I had troubles to migrate my Windows installation from VMWare to VirtualBox. When booting the vmware created partition in virtualbox, I got "NTLDR not found". So I sharpened the knives and got down to business with vmware's gdb interface and virtualbox's internal debugger. Tracing the execution showed that the BIOSes of the two products reported different geometries on the INT 13h interface. The generic method contained in the boot loader to read a sector from disk is "clever" as it checks whether the sector is below the maximum sector index that is reachable with the CHS geometry reported by the BIOS. If not, it uses the LBA interface of the BIOS. If yes, the cleverness of the boot loader suddenly vanishes. Instead of using the BIOS reported geometry to break the absolute sector down into its CHS components, the boot loader uses a geometry stored in the so called BIOS parameter block. That's a section of the first sector embedded into the boo…