Страницы: 1
Коротко суть проблемы — никакое сочетание опций командной строки не позволяет добиться в Firefox следующего поведения:
* Если указанный профиль еще не запущен, он запускается, и в нём открывается ссылка.
* Если указанный профиль уже запущен, в нём открывается ссылка. Именно в указанном профиле, а не в первой попавшейся запущенной копии FF.
Я предполагал, раз эту надоедливую проблему не фиксят, значит там надо переворотить прилично кода, и проблема, возможно, лежит на уровне архитектуры одного из компонет. Оказалось — решение составляет пять срочек кода.
Патч:
diff -r 89b5fccb0514 toolkit/xre/nsAppRunner.cpp --- a/toolkit/xre/nsAppRunner.cpp Thu Jul 14 12:20:34 2011 -0400 +++ b/toolkit/xre/nsAppRunner.cpp Sat Jul 23 03:14:32 2011 +0700 @@ -461,6 +461,8 @@ if (strimatch(aArg, arg)) { if (aRemArg) RemoveArg(curarg); + else + ++curarg; if (!aParam) { ar = ARG_FOUND; break; @@ -1408,10 +1410,17 @@ nsresult rv; ArgResult ar; + const char *profile = 0; nsCAutoString program(gAppData->name); ToLowerCase(program); const char *username = getenv("LOGNAME"); + ar = CheckArg("p", PR_FALSE, &profile, PR_FALSE); + if (ar == ARG_BAD) { + PR_fprintf(PR_STDERR, "Error: argument -p requires a profile name\n"); + return REMOTE_ARG_BAD; + } + const char *temp = nsnull; ar = CheckArg("a", PR_TRUE, &temp); if (ar == ARG_BAD) { @@ -1434,7 +1443,7 @@ nsXPIDLCString response; PRBool success = PR_FALSE; - rv = client.SendCommandLine(program.get(), username, nsnull, + rv = client.SendCommandLine(program.get(), username, profile, gArgc, gArgv, aDesktopStartupID, getter_Copies(response), &success); // did the command fail?
Да, если вы захотите написать, что уже есть опция -no-remote, почитайте более подробное описание проблемы у меня в блоге и подумайте над тем, почему в реальности от -no-remote нет толку.
Кто может составить грамотное описание бага и запостить патч в багтреке — у меня огромная просьба, сделайте это. Думаю, если это сделает человек, разбирающийся в особенностях общения с разработчиками Fx, то будет больше шансов на запиливание исправления в браузер.
Отсутствует
Clr
А как же
-profile "path\to\profile\dir"
?
Прошлое – это локомотив, который тянет за собой будущее. Бывает, что это прошлое вдобавок чужое. Ты едешь спиной вперед и видишь только то, что уже исчезло. А чтобы сойти с поезда, нужен билет. Ты держишь его в руках. Но кому ты его предъявишь?
Виктор Пелевин. Желтая стрела
Отсутствует
Clr
А как же
-profile "path\to\profile\dir"
?
Хм. Если бы ты проверил, прежде чем спрашивать, ты бы не стал задавать вопрос. — http://www.linux.org.ru/jump-message.jsp?msgid=6527213&cid=6527652
Отсутствует
Clr
Я про обработку такого параметра в патче.
Прошлое – это локомотив, который тянет за собой будущее. Бывает, что это прошлое вдобавок чужое. Ты едешь спиной вперед и видишь только то, что уже исчезло. А чтобы сойти с поезда, нужен билет. Ты держишь его в руках. Но кому ты его предъявишь?
Виктор Пелевин. Желтая стрела
Отсутствует
Clr
Я про обработку такого параметра в патче.
А, ты в этом смысле. Извини. Я когда гуглил проблему, задолбался мысленно отсеивать советы типа «используйте опции -P и -profile», вот и тебя зафильтровал.
-profile не обрабатывается HandleRemoteArgument, которая отвечает за опцию -remote. Я просто сделал по аналогии.
Если добавлять обработку -profile в RemoteCommandLine, её для консистентности надо добавить и в HandleRemoteArgument. А это логически уже другой баг и другой патч.
Отсутствует
Clr
Дело в том, что (по крайней мере в Windows) путь к профилю (чтобы работало без записей в profiles.ini) можно передать только через -profile "путь".
В портативной версии именно так и делается.
Прошлое – это локомотив, который тянет за собой будущее. Бывает, что это прошлое вдобавок чужое. Ты едешь спиной вперед и видишь только то, что уже исчезло. А чтобы сойти с поезда, нужен билет. Ты держишь его в руках. Но кому ты его предъявишь?
Виктор Пелевин. Желтая стрела
Отсутствует
Infocatcher
Я не совсем понял — вы хотите сказать, что опция -P не работает под Windows?
У меня нет Windows, но судя по коду, в реализации nsToolkitProfileService нет ничего OS-специфичного, поиск профилей выполняется одинаково.
То, что -profile необходим для работы с портативной копией — это понятно.
Отсутствует
Я не совсем понял — вы хотите сказать, что опция -P не работает под Windows?
Работает, но передать можно только имя профиля, прописанное в profiles.ini.
Прошлое – это локомотив, который тянет за собой будущее. Бывает, что это прошлое вдобавок чужое. Ты едешь спиной вперед и видишь только то, что уже исчезло. А чтобы сойти с поезда, нужен билет. Ты держишь его в руках. Но кому ты его предъявишь?
Виктор Пелевин. Желтая стрела
Отсутствует
Работает, но передать можно только имя профиля, прописанное в profiles.ini.
Лучше так, чем никак.
Я посмотрел, что происходит при открытии профиля через -profile — в этом случае браузер не устанавливает имя профиля для «прослушки». Т.е. просто обработку -profile в код RemoteCommandLine не добавить — надо научить работающую копию браузера говорить «я обрабатывают такой-то профиль, открытый по такому-то пути».
Здесь надо вносить довольно много изменений в код, но самая главная проблема — а какое имя брать для профиля, если он указан через полный путь? Имена находятся в profiles.ini, прочие профили безымянные.
Отсутствует
Тема перенесена из форума «Firefox» в форум «Разработка».
Do not meddle in the affairs of Wizards, for they are subtle and quick to anger.
Отсутствует
По поводу -profile мне пришло в голову вполне очевидное решение — в качестве имени профиля в этом случае можно использовать полный путь к каталогу профиля. Это выглядит логично и требует, кажется, минимальных изменений в коде, по сравнению с остальными вариантами.
Отсутствует
Clr
А как же
-profile "path\to\profile\dir"
?
Подскажите, пожалуйста, такой параметр позволяет полностью избежать обращение к profile.ini в %Documents and Settings%\%user%\Application Data\Mozilla\Firefox\
?
Отредактировано Eman (29-11-2011 23:28:55)
Отсутствует
Страницы: 1