- Package:
- iceweasel
- Source:
- firefox-esr
- Submitter:
- Daniel Jacobowitz
- Date:
- 2014-12-28 23:27:05 UTC
- Severity:
- normal
- Tags:
This is related to the fix for bug #344849.
First:
case "${arg}" in
.... -P | -CreateProfile)
prev=${arg}
continue
;;
esac
Then:
if [ "${prev}" ]; then
case "${prev}" in
-P|-CreateProfile)
case "${arg}" in
default) APPLICATION_ID=firefox ;;
*) APPLICATION_ID=firefox--"${arg}" ;;
esac
set "$@" "${prev}" "${arg}"
;;
Then:
elif [ "${arg}" ]; then
case "$arg" in
-P | -CreateProfile | -no-remote)
MOZ_NO_REMOTE=1
export MOZ_NO_REMOTE
That's never going to trigger. When the argument was received it was stored
in prev, and later it was processed from prev. It will never reach the
elif.
Fixing that won't fix the underlying bug, though, since the MOZ_NO_REMOTE
workaround does not appear to work. I just tried it; maybe I'm
misunderstanding. I've got a single firefox running using the default
profile and application ID during all these tests.
% firefox -P hacking -a other
-> Starts a new firefox process, does not return until that is closed.
-> I close it. Good so far.
% firefox -a other
-> Error dialog. I've gathered that this is expected, but the
-> error message doesn't explain what's going on and neither does
-> the man page. I close the dialog.
% firefox -P hacking -a firefox
-> Firefox opens a new window in the default profile, ignoring -P.
-> NOTE: This seems wrong.
-> I close it.
% firefox -P hacking -a firefox -no-remote
-> Firefox opens a new window in the alternate profile. I now have
-> two running with the same agent ID, presumably firefox does not
-> check at startup with MOZ_NO_REMOTE. A little strange. I close it.
% firefox -P hacking -a other
-> Firefox opens a new binary in the alternate profile automatically.
-> Good. I move it to the background (do not close it).
% firefox -P hacking -a other
-> Error dialog. It has failed to communicate with either of the
-> running firefox sessions. I can't tell if this is expected
-> or not.
% firefox -P hacking -a other -no-remote
-> Error dialog again. Huh? Same one, could not communicate
-> with the remote process, not something sensible like "profile in use".
-> Changing the application ID has no effect.
So, I can now run up to a single firefox window per profile for alternate
profiles, which is better than nothing, but not by a lot.
Hi Daniel, * Daniel Jacobowitz (dan@debian.org) wrote: Ok, well that problem should be fixed in the latest upload. Hmm, could you try repeating these experiments with --verbose and sending the results?
Yes, looks good now. Sure. FIREFOX_DSP= APPLICATION_ID=other CMDLINE_DISPLAY= DISPLAY=:0.0 OPTIONS=-P hacking -a other DEBUG=0 DEBUGGER= MOZ_DISABLE_PANGO= MOZ_NO_REMOTE=1 Running: /usr/lib/firefox/firefox-bin -P hacking -a other Same results. FIREFOX_DSP= APPLICATION_ID=other CMDLINE_DISPLAY= DISPLAY=:0.0 OPTIONS=-a other DEBUG=0 DEBUGGER= MOZ_DISABLE_PANGO= MOZ_NO_REMOTE= Running: /usr/lib/firefox/firefox-bin -a other Same results. The dialog box still says: "Firefox is already running, but it is not responding. To open a new window, you must first close the existing Firefox process, or restart your system." FIREFOX_DSP= APPLICATION_ID=firefox CMDLINE_DISPLAY= DISPLAY=:0.0 OPTIONS=-P hacking -a firefox DEBUG=0 DEBUGGER= MOZ_DISABLE_PANGO= MOZ_NO_REMOTE=1 Running: /usr/lib/firefox/firefox-bin -P hacking -a firefox I get a new window in the 'hacking' profile. -P is not ignored. This is confusing to me; I would have expected that the already running firefox (which has options -P default -a firefox) would have objected to this. But we've disabled remote operation so I guess we never asked it :-) Behaves exactly as -P hacking -a firefox now. FIREFOX_DSP= APPLICATION_ID=other CMDLINE_DISPLAY= DISPLAY=:0.0 OPTIONS=-P hacking -a other DEBUG=0 DEBUGGER= MOZ_DISABLE_PANGO= MOZ_NO_REMOTE=1 Running: /usr/lib/firefox/firefox-bin -P hacking -a other Sam results. FIREFOX_DSP= APPLICATION_ID=other CMDLINE_DISPLAY= DISPLAY=:0.0 OPTIONS=-P hacking -a other DEBUG=0 DEBUGGER= MOZ_DISABLE_PANGO= MOZ_NO_REMOTE=1 Running: /usr/lib/firefox/firefox-bin -P hacking -a other Same error dialog. Same as without -no-remote, of course. By default firefox uses the profile from profiles.ini. I used to have some trouble with it changing the default unexpectedly, so my GNOME toolbar button for firefox says "firefox -P default". Now that the implicit -no-remote behavior has been fixed, this generates the same dialog box as several of the cases above. Try it: firefox & sleep 2 # So it pops up a window firefox -P default -> error dialog All I want is to be able to have two running firefox sessions, in different profiles, and two buttons on my toolbar to pop up a new windows, one for each profile. Using just -a doesn't work either: firefox & firefox -P hacking -a other & firefox -a firefox # Works! firefox -P hacking -a other # Error box firefox -a other # Error box
Dear Firefox/Iceweasel user, Thanks for your interest in Firefox/Iceweasel and the bug report you have contributed. Your bug report [0] was done for a version which isn't a part of debian anymore. Debian 4.0 (Etch) was released with version 2.0.0.3. Please reproduce your bug on an updated version of Iceweasel and confirm it still exists, or close it as irrelevant for recent versions. If you don't know or are not sure how to update or close your bug report, please contact me directly, and I'll help you. IMPORTANT: In any case, please provide version info, as we use it to determine the relevance of the bug. As this bug is quite old, I intend to close it if you don't update your bug report in the next 6 weeks. This is the time line for the old bugs cleanup: 1. October 1st - first notice. 2. October 15th - Second notice. 3. October 29th - Third notice. 4. November 12th - Closing the bug. Please help the Firefox/Iceweasel maintainer to help you (: [0] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=366129
Dear Firefox/Iceweasel user, Thanks for your interest in Firefox/Iceweasel and the bug report you have contributed. Your bug report [0] was done for a version which isn't a part of debian anymore. Debian 4.0 (Etch) was released with version 2.0.0.3. Please reproduce your bug on an updated version of Iceweasel and confirm it still exists, or close it as irrelevant for recent versions. If you don't know or are not sure how to update or close your bug report, please contact me directly, and I'll help you. IMPORTANT: In any case, please provide version info, as we use it to determine the relevance of the bug. As this bug is quite old, I intend to close it if you don't update your bug report in the next 6 weeks. This is the time line for the old bugs cleanup: 1. October 1st - first notice. 2. October 15th - Second notice. 3. October 29th - Third notice. 4. November 12th - Closing the bug. Please help the Firefox/Iceweasel maintainer to help you (: [0] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=366129
found 366129 2.0.0.7-2 thanks Behavior has not changed since the last time I updated the report, in July 2006.
Version: 3.0.1-1 I'm pretty confident this was fixed before the version currently in Lenny. The version in squeeze or unstable may have a different behaviour, though, as we reverted to the upstream behaviour, in which case you need both -P and --no-remote. Cheers, Mike
retitle 366129 Doesn't support the x-remote interface with a secondary profile thanks Ah, this is a different bug from what I thought, then. Mike
found 366129 3.5.5-1 thanks Using either 3.5.5-1 or unmodified upstream firefox 3.5.5, I get exactly the same behavior as I did in the original report in 2006; for instance there is no way to open a new window in an alternate profile. I don't know about the version in lenny. To be clear, I'm not sure which of the other behaviors are bugs, but I'm sure that the second "-P hacking -a other" or the "-P hacking -a other -no-remote" case is a bug; there is no way to click on a shortcut and have it open a second window in a second copy of firefox. I'm fine with wontfix now; I was using the second isolated profile so I didn't have to mess around with flash in my actual web browser. But both nspluginwrapper and the Adobe plugin are in such poor shape now that I use Chrome for flash instead.
--- Please enter the report below this line. ---
Hi!
with the Iceweasel 3.5, I can't start more one profile.
The command:
$ iceweasel -ProfileManager
open a new windows of iceweasel if it was ever run.
I need to start more one different profile in the same time.
(I can come back to old version 3.0 of Iceweasel to wait :) )
Thank you.
G
Debian Release: squeeze/sid
500 unstable ftp.gajim.org
500 unstable ftp.fr.debian.org
500 testing security.debian.org
500 testing debian.ens-cachan.fr
1 experimental ftp.fr.debian.org
--- Package information. ---
Depends (Version) | Installed
==========================================-+-==============
fontconfig | 2.8.0-2
psmisc | 22.10-1
procps | 1:3.2.8-7
debianutils (>= 1.16) | 3.2.2
libc6 (>= 2.3.6-6~) | 2.10.2-3
libgcc1 (>= 1:4.1.1) | 1:4.4.2-9
libglib2.0-0 (>= 2.12.0) | 2.22.4-1
libgtk2.0-0 (>= 2.8.0) | 2.18.6-1
libnspr4-0d (>= 1.8.0.10) | 4.8.3-1
libstdc++6 (>= 4.1.1) | 4.4.2-9
xulrunner-1.9.1 | 1.9.1.6-1
libasound2 (>> 1.0.18) | 1.0.21a-1
libatk1.0-0 (>= 1.20.0) | 1.28.0-1
libbz2-1.0 | 1.0.5-4
libc6 (>= 2.3.6-6~) | 2.10.2-3
libcairo2 (>= 1.8.8) | 1.8.8-2
libdbus-1-3 (>= 1.0.2) | 1.2.20-2
libfontconfig1 (>= 2.4.0) | 2.8.0-2
libfreetype6 (>= 2.2.1) | 2.3.11-1
libgcc1 (>= 1:4.1.1) | 1:4.4.2-9
libglib2.0-0 (>= 2.16.0) | 2.22.4-1
libgtk2.0-0 (>= 2.18.0) | 2.18.6-1
libhunspell-1.2-0 (>= 1.2.8) | 1.2.8-6
libjpeg62 | 6b-15
libmozjs2d (>= 1.9.1.4) | 1.9.1.6-1
libnspr4-0d (>> 4.7.1-1) | 4.8.3-1
libnss3-1d (>= 3.12.3) | 3.12.5-2
libpango1.0-0 (>= 1.14.0) | 1.26.2-1
libpng12-0 (>= 1.2.13-4) | 1.2.42-1
libreadline6 | 6.1-1
libsqlite3-0 (>= 3.6.21) | 3.6.22-1
libstartup-notification0 (>= 0.10) | 0.10-1
libstdc++6 (>= 4.1.1) | 4.4.2-9
libx11-6 (>= 0) | 2:1.3.3-1
libxrender1 | 1:0.9.5-1
libxt6 | 1:1.0.7-1
zlib1g (>= 1:1.1.4) | 1:1.2.3.4.dfsg-3
Package's Recommends field is empty.
Suggests (Version) | Installed
============================================-+-===========
ttf-lyx | 1.6.5-1
OR latex-xft-fonts | 1.6.5-1
xfonts-mathml | 4
ttf-mathematica4.1 |
xprint |
mozplugger |
libgssapi-krb5-2 | 1.8+dfsg~alpha1-7
xulrunner-1.9.1-gnome-support | 1.9.1.1-1
--- Output from package bug script ---
Check out the manual page:
-ProfileManager
Start with profile manager. May require -no-remote,
see below.
Note this has nothing to do with the original bug report.
Cheers,
Mike
Dear Maintainer, I have tried to fix this upstream, but they have rejected my patch for (to me) incomprehensible reasons. Nonetheless, there is a patch available at https://bugzilla.mozilla.org/show_bug.cgi?id=643418 and I would ask that it be considered for inclusion in iceweasel even if not in firefox proper. Thanks much! --nwf;
This issue seems to persist in Iceweasel 31. I run the following steps in
order:
0. Open Iceweasel with profile Foo. Keep it open.
1. iceweasel -P Bar http://example.com
-> Opens example.com in Foo window, bad!
2. iceweasel -P Bar -new-instance http://example.com
-> Opens example.com in new Bar window, ok. Keep it open.
3. iceweasel -P Bar http://example.com
-> Opens example.com in Foo window, bad!
4. iceweasel -P Bar (-new-instace|-no-remote) http://example.com
-> "Iceweasel is already running, but not responding." error.
I think this behaviour is a manifestation of this same bug.
Since https://bugzilla.mozilla.org/show_bug.cgi?id=643418 and
https://bugzilla.mozilla.org/show_bug.cgi?id=486172 do not seem to make
progress in fixing this, I support Nathaniel in applying his patch so that new
windows/tabs can actually be opened in different running profiles.
Thanks!