Closed Bug 170609 Opened 22 years ago Closed 21 years ago

-remote openurl() opens Mozilla window if Mozilla is running

Categories

(Firefox :: General, defect)

Product:
Firefox
Component:
General
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Milestone:
Future

People

(Reporter: lawrenceteo, Assigned: bryner)

References

(Depends on 1 open bug)

Details

Attachments

(1 file)

patch
15.62 KB, patch
hyatt
: review+
Details | Diff | Splinter Review
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2b) Gecko/20020923 Phoenix/0.1 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2b) Gecko/20020923 Phoenix/0.1 If Mozilla and Phoenix are both running at the same time, using the "-remote openurl()" command on Phoenix opens the Mozilla window instead of Phoenix. Reproducible: Always Steps to Reproduce: 1. Start Mozilla. 2. Start Phoenix 3. At the commandline, cd to the phoenix install directory and type: ./phoenix -remote 'openurl(http://www.kuro5hin.org/)' (or any other URL) Actual Results: The Mozilla window opens the URL. Expected Results: The Phoenix window should have opened the URL instead of Mozilla.
essentially (for the purposes of XRemote), Phoenix identifies itself as Mozilla. And the Phoenix xremote-client looks for a version of Mozilla. It will grab a Mozilla or Phoenix window, whichever one was used most recently. Mozilla will also be perfectly happy to grab a Phoenix window. The problem exists in: http://lxr.mozilla.org/mozilla/source/widget/src/gtk/nsGtkMozRemoteHelper.cpp#33 http://lxr.mozilla.org/mozilla/source/widget/src/gtk/nsGtkMozRemoteHelper.cpp#57 and then here: http://lxr.mozilla.org/mozilla/source/widget/src/xremoteclient/XRemoteClient.cpp#41 http://lxr.mozilla.org/mozilla/source/widget/src/xremoteclient/XRemoteClient.cpp#196 not knowing how Phoenix is built, I have NO idea how (or if) this can be remedied within Phoenix.
setting status to new. bryner, can you help us here.
Status: UNCONFIRMED → NEW
Ever confirmed: true
*** Bug 173314 has been marked as a duplicate of this bug. ***
*** Bug 173806 has been marked as a duplicate of this bug. ***
this bug is going to screw things up for people using Mozilla RPMs (and Phoenix RPMs if they ever exist)
doing #ifdef MOZ_PHOENIX to redefine MOZILLA_VERSION_PROP in nsGtkMozRemoteHelper.cpp and XRemoteClient.cpp is sufficient to fix this bug.
We should make this generic and use the product name defined in the nsXREAppData.
Attached patch patch — — Splinter Review
Comment on attachment 102745 [details] [diff] [review] patch r=hyatt
Attachment #102745 - Flags: review+
Am I reading this right? Would this change the atoms to PHOENIX_VERSION, etc? This will break an incredible number of existing clients and is completely unacceptable. The correct way to do this is to use the version in the _MOZILLA_VERSION atom and match against it. I guess we can do something like 5.0/phonix or 5.0/mozilla if you want. But we should not be changing these atom names since this protocol has been around for a very, very long time.
But that's actually what we want to do. We don't want phoenix and mozilla xremote to interfere with each other. They are two totally separate apps.
Also, if there are external programs that use the X atoms directly, instead of just calling "mozilla -remote", we would have to contend with these apps not matching the version string correctly until they are updated. If the vast majority of apps use "mozilla -remote" for xremote functionality then we can pretty much do whatever we'd like, including putting the product name in the version string, if you like that better.
There are lots of apps out there that use the protocol directly, some that use mozilla -remote and some that still use netscape -remote. I don't want to see any of them broken. Phonix should work with them as well. We can solve this for mozilla -remote (which I think should search for mozilla first and then fall back to anything else it finds) and phoenix -remote. The real solution here is to fix the client side code to be much smarter.
*** Bug 175069 has been marked as a duplicate of this bug. ***
-> bryner
Assignee: blaker → bryner
so is the patch here obsolete? can someone mark it so if it is? thanks.
Should openURL also differentiate between profiles? I've been using Phoenix 0.5 with a "default" and a "work" profile. It would be nice if one could do phoenix -P default -remote 'openURL(http://mozilla.org)' and phoenix -P work -remote 'openURL(http://mozilla.org)' And have the correct thing happen. Currently, whichever browser+profile was opened first responds.
huh? that bug is about mail filters
Blocks: 177996
I'm wondering (out loud) about how the changes in the Mozilla "suite" will effect this bug. Now that Firebird will be incorporated as the primary broswer application in the traditional Mozilla package, will this bug go away naturally since there won't be multiple browsers fighting to fulfill the request? If not, what are the chances of a Milestone being set? I'm thinking this would be good to complete prior to the merging of Firebird into the suite. If not, it seems that the merge would actually be breaking functionality that currently works. Not being a programmer, I'm not sure if/how I can help other than testing. Hope that's enough!
*** Bug 207453 has been marked as a duplicate of this bug. ***
From bug #207453: this impacts also if you'd like to run Moz.Firebird & Thunderbird in parallel.
Target Milestone: --- → After Firebird 1.0
In case this needs pointing out, Firebird may run just fine in spite of this bug in most circumstances, and Thunderbird too, but if users plan to use both, it's a big problem. Since I now use Mozilla for both browsing & e-mail, I am stuck using Mozilla instead of Firebird/Thunderbird until either this bug is fixed or I find a different mail program. I hope that didn't come across as antagonistic (did not mean it that way). I just want to point out that while this may not be a blocker for either individual component, for me it's a blocker for using the componentized Mozilla bits at all.
*** Bug 214503 has been marked as a duplicate of this bug. ***
*** Bug 214683 has been marked as a duplicate of this bug. ***
I'm getting further reports that pages are being loaded into Thunderbird due to this bug. That is a Bad Thing, and is probably worth Firebird 1.0.
QA Contact: asa
To answer Asa's question in comment 16, the patch no longer applies cleanly to the CVS trunk. My naive/trivial attempts to clean up the rejected blocks lead to code that won't link, so I can't attach a newer patch. On a related note, the patch only distinguishes between Mozilla and Firebird; it should probably take Thunderbird into account as well, although (I believe) a Mozilla/Thunderbird combination is less likely to occur. Comments 22, 23 and especially 26 seem to indicate a pre-1.0 target might be appropriate.
Maybe it's just me, but this seems like a pretty serious bug. It effectively prevents anyone from using thunderbird and firebird at the same time. If the monolithic Mozilla is deprecated, this is a bad thing. (It also effectively prevents people from testing these apps since they can't easily be used for normal day-to-day activities). See also: bug 217752 bug 226333 (but bug 226333, comment 1 suggests this is noted in the release notes, but I couldn't find it) bug 226777 bug 226780 bug 227486 bug 227658 bug 229021 And last but not least bug 177996 (in particular, bug 177996, comment 26 and up)
*** Bug 228631 has been marked as a duplicate of this bug. ***
Does anyone know of a work-around for this bug? I just downloaded Firefox, and I've found that I can't use it. I use the integrated Mozilla for email, so in order to open a web browser I have to close down my email. I wondered if switching to Thunderbird for email would help, but if I'm reading the comments correctly, it won't. It will be a sad day if I have to switch to Evolution... If there is no easy work-around, might I suggest that this bug be redesignated as a blocker for any future Firefox release? Firefox is virtually unusable on Linux until it is fixed. Please don't read this comment as a flame, it's not meant that way. It's only because I'm excited about Firefox that I am motivated to provide feedback. I love the browser and I'm frustrated that I can't use it. :-)
The workaround I use (thanks to bug 227486 comment 4) is to write wrapper scripts that export a unique LOGNAME environment variable for each app (such as $USER+mozilla, $USER+firefox, $USER+thunderbird), call mozilla-xremote-client with an appropriate command, and launch the app if that fails. You have to be careful that the wrong LOGNAME doesn't bleed through when one app calls another. This hack won't work if you use any apps that directly call mozilla-xremote-client or use the xremote protocol. Obvously, a user shouldn't have to do that. I know the Mozilla team has put a lot of effort into producing a great browser and mail client for Linux, so it's a shame that one problem like this makes them almost unusable. If the apps can't be fixed any time soon, they really need to be shipped with a script along those lines that makes them Just Work.
Flags: blocking0.9?
Target is After Firefox 1.0, so blocking0.9-.
Flags: blocking0.9? → blocking0.9-
fixed by bug 237283 removing bogus dependency
No longer blocks: 177996
Status: NEW → RESOLVED
Closed: 21 years ago
Depends on: 237283
Resolution: --- → FIXED
The latest Fedora RPM seems to fix this bug for me. Many thanks.
Not sure if this is the same bug or not, but when I installed Firefox from Dag Wieers' yum repo, whether Mozilla was running or not, running "firefox" from the commandline and using the menu item both opened Mozilla until I removed it from my system.
It sounds like the same bug. Try the Firefox package from the Fedora extras, that fixed the problem for me.
*** Bug 233576 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: