Last Comment Bug 716361 - firefox -remote 'OpenUrl(about:blank)' tells "Error: No running window found"
: firefox -remote 'OpenUrl(about:blank)' tells "Error: No running window found"
Status: RESOLVED DUPLICATE of bug 716110
:
Product: Firefox
Classification: Client Software
Component: Untriaged (show other bugs)
: 9 Branch
: x86_64 Linux
: -- normal (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-01-08 06:14 PST by Alex Garel
Modified: 2012-03-20 21:30 PDT (History)
2 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Small C program to search for X11 windows with Mozilla properties. (1.20 KB, text/plain)
2012-01-19 22:05 PST, Jed Davis [:jld] {⏰UTC-6}
no flags Details

Description Alex Garel 2012-01-08 06:14:38 PST
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)'
Comment 1 Jed Davis [:jld] {⏰UTC-6} 2012-01-18 23:22:10 PST
Also seeing this (9.0.1, Linux/amd64).  It doesn't appear to work either with or without the -P flag.
Comment 2 Jed Davis [:jld] {⏰UTC-6} 2012-01-18 23:40:30 PST
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.
Comment 3 Jed Davis [:jld] {⏰UTC-6} 2012-01-19 22:04:18 PST
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.
Comment 4 Jed Davis [:jld] {⏰UTC-6} 2012-01-19 22:05:49 PST
Created attachment 590105 [details]
Small C program to search for X11 windows with Mozilla properties.
Comment 5 Jed Davis [:jld] {⏰UTC-6} 2012-01-20 00:07:13 PST
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.
Comment 6 Jed Davis [:jld] {⏰UTC-6} 2012-01-20 00:25:53 PST
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.
Comment 7 Alex Garel 2012-01-20 00:42:28 PST
Thanks Jed for your investigation. I've voted for PR 716110 and I mark this as a duplicate of PR 716110.

*** This bug has been marked as a duplicate of bug 716110 ***

Note You need to log in before you can comment on or make changes to this bug.