Closed Bug 716361 Opened 12 years ago Closed 12 years ago

firefox -remote 'OpenUrl(about:blank)' tells "Error: No running window found"

Categories

(Firefox :: Untriaged, defect)

9 Branch
x86_64
Linux
defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 716110

People

(Reporter: alex, Unassigned)

Details

Attachments

(1 file)

User Agent: Mozilla/5.0 (Ubuntu; X11; Linux x86_64; rv:9.0.1) Gecko/20100101 Firefox/9.0.1
Build ID: 20111221202647

Steps to reproduce:

$ uname -a
Linux 2.6.38-13-generic #53-Ubuntu SMP Mon Nov 28 19:33:45 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux

$ firefox -v
Mozilla Firefox 9.0.1

Bug since last firefox update, yesterday.




Actual results:

One firefox instance using myprofile already running.

$ firefox -P myprofile -remote 'OpenUrl(about:blank)'
Error: No running window found



Expected results:

A new window using myprofile shall have appeared.

I normally use a lot the -remote 'OpenUrl(about:blank)' for I use more than two different firefox profile on my desktop (one for web dev with firebug, one for other url, sometimes to test application with different users). I have two launcher to open new window of each instance with firefox -P myprofile -remote 'OpenUrl(about:blank)'
Also seeing this (9.0.1, Linux/amd64).  It doesn't appear to work either with or without the -P flag.
A discovery: I have, for unrelated reasons, a chroot with a copy of Firefox 3.0.6 for i386.  The new firefox can successfully find and signal a window of the old firefox, but not vice versa.  This suggests that a regression was introduced into the "server" side of -remote.
I now have a build of last night's mozilla-central tip (58e933465c36), and have been doing some testing.

At this point I must confess — and I should have done so initially — that I'm on Debian and the previously mentioned firefoxes are in fact iceweasels.  This might or might not be relevant; none of Debian's patches appear to touch this part of the code, and the original submitter of the PR is using Ubuntu, which I believe lacks the fox/weasel branding changes.  The animal name is used as the value of the _MOZILLA_PROGRAM property, but that shouldn't matter as long as it's the same program on both ends, and can be overridden with the undocumented "-a" flag in any case.

I have written a small C program that traverses the X server's window tree looking for windows with _MOZILLA_PROGRAM and _MOZILLA_VERSION properties.  The current firefox has "firefox" and "5.1" (which is the expected value; it's the version of the protocol, the browser), the 3.0.6 firefox has "iceweasel" and "5.1", and the 9.0.1 iceweasel doesn't have either property set.  I'll attach the program and investigate further.
Okay, I've found my problem: my window manager was running it with -no-remote, which used to mean "just start the browser; don't try to find a running instance" (so that I'd get the profile manager; I dimly recall that -ProfileManager used to not work, and -no-remote was the only way I found to get that result).

It seems that option now also means "and don't accept remote commands, either".  (And, of course, when I was running various test versions I just ran them from a shell with no arguments, so they didn't do that.)  And *that* behavior occurs both with 9.0.1 and in -central — they accept remote commands if and only if -no-remote isn't given.  I'll see if I can annotate this to a revision, for my own curiosity if nothing else.
Blame is to changeset ba38da32b848, done for PR 650078.  Indeed, -ProfileManager does *not* work — if there's a running instance, it will open a window in it instead, and the same is true for -P.  So, it completely broke concurrent multiple profiles with remoting, which is not actually an unheard-of use case.  But I'm not the first to trip over this; PR 716110 has already been filed.
Thanks Jed for your investigation. I've voted for PR 716110 and I mark this as a duplicate of PR 716110.
Status: UNCONFIRMED → RESOLVED
Closed: 12 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: