Date: Mon, 28 Feb 2005 02:27:01 +0000 From: Jeremy Prior <jez@netcraft.com> To: Jose M Rodriguez <josemi@freebsd.jazztel.es> Cc: freebsd-gnome@freebsd.org Subject: Re: firefox 1.0.1 profiles Message-ID: <1109557621.56667.32.camel@chagford.netcraft.com> In-Reply-To: <200502280110.03752.josemi@freebsd.jazztel.es> References: <1109541743.56667.10.camel@chagford.netcraft.com> <1109547595.39851.28.camel@shumai.marcuscom.com> <200502280110.03752.josemi@freebsd.jazztel.es>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 2005-02-28 at 01:10 +0100, Jose M Rodriguez wrote:
> Add processing for -P may be easy for direct invocation, But I must
> rethink if this is workable for remote protocol.
I don't think that profiles have ever really worked properly when used
in conjunction with remote commands.
ie
% firefox -P default &
% firefox -P anotherprofile -remote "openURL('about:blank',new-window)"
opens up a new window in the `default' profile.
All I was trying to do was make existing functionality work again!
> Also, what is seen is more or less a warning about use of remote
> protocol, but this may still work on direct invocation.
Ideally, the wrapper would check to see whether the requested profile
matches the one for the running firefox and start a fresh copy if they
don't match. However, I can't see a way of determining the profile of a
running copy remotely so this is going to be difficult to achieve
without extending the remote protocol. As profiles are a little-used
feature (they are only used by developers and people who share an
account :-) there's probably not much interest in doing this.
jez
--
Jeremy Prior <jez@netcraft.com> http://www.netcraft.com/
Netcraft Ltd, Treenwood Ho, Rowden La, Bradford-on-Avon, BA15 2AZ. UK
Tel: +44-1225-867111 (switchboard) Fax: +44-8700-517767
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1109557621.56667.32.camel>