以编程方式创建Firefox配置文件 [英] Programmatically create Firefox profiles

查看:110
本文介绍了以编程方式创建Firefox配置文件的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

问题:

是否有一种简单的编程方式来创建新的Firefox配置文件?

Is there a simple programmatic way to create new Firefox profiles?

nsIToolkitProfileService似乎可以解决问题,但是文档说:

nsIToolkitProfileService looks like it might do the trick but the docs say:

从Gecko 18开始(Firefox 18.0/Thunderbird 18.0/SeaMonkey 2.15/Firefox OS 1.0.1),则不应再使用此服务或nsIToolkitProfile

Starting in Gecko 18 (Firefox 18.0 / Thunderbird 18.0 / SeaMonkey 2.15 / Firefox OS 1.0.1), you should no longer use either this service or nsIToolkitProfile

为什么:

我对此很感兴趣,因为我认为它可以用来使Firefox的独立可执行文件非常容易运行(例如,每个应用程序的任务栏中可以有一个完全独立的图标),而无需现在已终止的Prism/Chromeless/WebRunner项目.

I am interested to do this because I think it could be used to get independent executables of Firefox running pretty easily (e.g., so one can have a wholly separate icon in the task bar for each app) without the need for the now defunct Prism/Chromeless/WebRunner projects.

我的方法是创建一个Firefox插件,允许用户指定Web应用程序URL,然后为他们自动为应用程序创建一个命名空间配置文件,例如"Executable1","Executable2"等.以及一个批处理文件,该批处理文件将针对该配置文件和应用调用命令行"-no-remote"参数(因为-no-remote似乎需要配置文件才能创建新实例(我拥有"-new-instance"参数看到在错误中提到的内容似乎对我不起作用.

My approach would be to create a Firefox add-on which allowed the user to specify a web app URL and then would auto-create for them a namespaced profile like "Executable1", "Executable2", etc. for the app as well as a batch file which would invoke the command line "-no-remote" argument against that profile and app (since -no-remote seems to require a profile to create a new instance (the "-new-instance" argument I have seen mentioned in a bug does not seem to work for me).

推荐答案

我的猜测是人们要么想要避免主线程I/O.或者有人讨论从应用程序中删除概要文件管理器,以加快启动速度并简化总体启动代码,因此,这可能就是原因.似乎是维基用户"victorporof"确实进行了此编辑,因此您可能应该ping他以获得解释(IIRC,他有一个@ mozilla.com地址,您可以轻松地通过Google搜索;)

My guess is that people either wanted to avoid main-thread I/O. Or there were talks to remove the profile manager from the app to make startup faster and simplify startup code in general, so that might be the reason. Seems like wiki user "victorporof" did make this edit, so you probably should ping him for an explanation (IIRC, he's got an @mozilla.com address you could easily google ;)

无论如何,一个新的配置文件只不过是一个空目录.该应用程序启动后实际上会复制/创建丢失的文件.这样您的附加组件就可以:

Anyway, a new profile isn't much more than an empty directory. The application will actually copy/create missing files as soon as it starts. So your add-on could just:

  • 在所需位置创建一个空目录.
  • 打开一个实例:-no-remote -profile $dir
  • 添加图标或其他内容.
  • 完成它.
  • (可选)与profiles.ini混淆,以便新的配置文件在常规配置文件管理器中列出.
  • Create an empty directory in the desired location.
  • Open an instance: -no-remote -profile $dir
  • Add icons or whatever.
  • Be done with it.
  • Optionally mess with profiles.ini, so that the new profile gets listed in the regular profile manager.

我经常从命令行执行诸如此类的操作

I regularly do stuff like this from command line, e.g.

mkdir -p central.profile && path/to/filefox -no-remote -profile $PWD/central.profile

或者只是继续使用nsITOolkitProfileService,直到将其真正删除为止. (这就是我可能要做的). FWIW,甚至还有一些新代码仍在使用它,例如(远程)调试器.

Or just continue using nsITOolkitProfileService until it is actually removed. (That's what I would probably do). FWIW, there is even newish code still using it, like the (remote) debugger.

此外,也许值得一看他们编写的独立的档案管理器上.

Also, might worth having a look at the standalone profile manager they coded up.

这篇关于以编程方式创建Firefox配置文件的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆