D. Hugh Redelmeier wrote, On 03/05/2008 03:39 PM:
| From: Tom Horsley <tom.horsley@xxxxxxx>
| I find the nspliginwrapper helper app sitting in 100% cpu loops
| most of the time with my firefox frozen. Using 32 bit firefox and
| no nspluginwrapper works much better for me (and I actually find it
| convenient to be able to run 64 bit firefox and know that annoying flash
| content won't appear :-).
I used to do that too. But the greatest inconvenience was that if you
had ff64 running, any attempt to run ff32 would just hand off the
request to ff64. Too smart.
Another manifestation: if I try to run ff remotely, the remote ff just
hands off the request to my local ff. And, if that request involved
file://, it will whine about there being no such file. Too smart.
The problem is in the script /usr/bin/firefox. I'm too lazy to hack
it. I don't actually know the consequences of two instances both
writing stuff into ~/.mozilla
How are you sure it is in the firefox script?
I just took a look at it (quickly) and did not see anything obvious that would
make the script do a choice for run a new copy vise connect to the running copy.
I too find it annoying that ff will not allow you to start a new separate
copy, and I only run in 32 bit land.
IIRC mozilla had an option to make it use the running copy, but it was not the
default, and it was a visible option (mozilla --help would show it) that the
user could choose. too bad that they have decided to A) make it the default
AND B) not give a switch to choose the other direction.
--
Todd Denniston
Crane Division, Naval Surface Warfare Center (NSWC Crane)
Harnessing the Power of Technology for the Warfighter
