147160 - Cannot instantiate a new instance of the browser when one is already open.

Status: VERIFIED INVALID

(SeaMonkey :: General, defect)

Description

[Satheesh]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0rc3) Gecko/20020523
BuildID:    20020523

When instantiating a new copy of the browser the system complains that the
default profile is in use.
I am NOT using the File->New->New Navigator Window. Instead I am clicking on the
browser button at the task bar.
I can send in a screenshot to prove this.

Reproducible: Always
Steps to Reproduce:
1. Open a new instance of the browser by clicking on the Mozilla icon on my task
bar.
2. Now try opening another instance then the error occurs.
3.

Actual Results:  Browser complains that default profile is in use cannot create
another one.

Expected Results:  Browser should open n number of instances.

I can send in a screenshot to prove this.

Comment 1

[Satheesh]

Attachment: this screen shot showz the bug.

This is a screen shot of the bug that occurs on my machine with the Mozilla RC3
version.

Comment 2

[R.K.Aa.]

Resolving as invalid. This is not a bug but the fix for bug 76431 to prevent
users from running multiple instances of mozilla using the same profile.

See also meta bug 135137.

Comment 3

[Matthias Versen [:Matti]]

verified invalid

if you want only a new browser window :
bug 122698

Comment 4

[Satheesh]

Resolved this.
I had a mozilla script from an rpm installation. This rpm script of mozilla does
solve the problem. The rpm script creates a new window of the same instance
(this is being written on a new window).
I'd really put the entire script here except that the license lingo confused the
life of me.
Cheers and I do appreciate the help.
Sats

Comment 5

[R.K.Aa.]

*** Bug 147812 has been marked as a duplicate of this bug. ***

Comment 6

[Tet]

Just marking it as invalid isn't an option. You haven't provided an
alternative or a workaround. As it stands, rc2 and earlier are usable
browsers and rc3 isn't. That's not a good situation to be in...

Comment 7

[Boris Zbarsky [:bzbarsky]]

*** Bug 147869 has been marked as a duplicate of this bug. ***

Comment 8

[Andrew Hagen]

As comment 2 stated, this behavior was fixed in bug 76431. That fix was
necessary to prevent multiple instances of Mozilla from overwriting profile data
and causing corruption of user data. Workarounds exist. See comment 4.

Comment 9

[Tet]

The workaround in comment 4 doesn't work. Yes, the startup script now
lets you open multiple browser windows, but only on the same display.
As I mentioned in my original report (bug 147812), I need to open Mozilla
on two different displays (in my case, :0.0 and :0.1). This still isn't
possible with a single profile, and is making rc2 a far better choice of
browser for me than 1.0. This bug is NOT invalid.

Comment 10

[Matthias Versen [:Matti]]

Tet: running 2 instances with the same profile corrupts the profile.
We don't want this and we don't let you do it because we got too many bug
reports with this problems.

Comment 11

[Tet]

I understand that, but if you're going to remove that ability, then you
need to provide a workaround of some sort to let users run multiple
instances of the browser. This could be as simple as a --force-corrupt-profile
flag, or it could be something else. Just out of curiosity, is this corruption
theoretical, or has it actually been causing real problems? Certainly in over
a year of running like this, I've never seen any signs of it. Even the ability
to just copy an existing profile would be better than what we've got now.

Comment 12

[Andrew Hagen]

If one instance of Mozilla can't put windows on two different displays, wouldn't
that be a separate bug?

Comment 13

[Matthias Versen [:Matti]]

You should be able to move a window to the second window...

Yes, it caused many bug reports and the cause of the problem in the bug is
difficult to find.
And we will not add an option sto disable that.

Comment 14

[Tet]

You can only move a window between screens if you're running Xinerama
(which I'm not, and which isn't supported by any non-XFree86 X server
that I know of). You also can't do it between displays. See the following
for an example of the problem:

mozilla &
Xnest :1 &
DISPLAY=:1 mozilla

Comment 15

[Andrew Hagen]

Is there an open bug on the problem with one instance, multiple displays?

Comment 16

[Tet]

In bug 122698, Blizzard implies that mozilla-xremote-client already knows
how to handle different displays. In practice, though, it doesn't seem to.
This isn't helped by the fact that I can't find any documentation for
mozilla-xremote-client...

To illustrate, compare:

  mozilla &
  mozilla-xremote-client 'ping()'
  echo $?

with

  Xnest :1 &
  DISPLAY=:1 mozilla &
  mozilla-xremote-client 'ping()'
  echo $?

The former returns 0, while the latter returns 2.

Comment 17

[R.K.Aa.]

*** Bug 151363 has been marked as a duplicate of this bug. ***

Comment 18

[R.K.Aa.]

*** Bug 151363 has been marked as a duplicate of this bug. ***

Comment 19

[Michael Hipp]

Okay, I got scolded and was told to post my comments about this particular
BugFeature(tm) here instead of one of the many others that have been filed about it.

I just know this ...

I can, with no problems whatsoever, run multiple instances of Opera, Konqueror,
Internet Explorer, Netscape, and even Mozilla (before 1.0rc3) with no worries
about "profile corruption". But all of a sudden, I can't.

I just know when I click on a link in Kmail that Mozilla refuses to bring it up
simply because another window is open.

This is a SHOWSTOPPER. This makes Mozilla largely useless as a browser.

So tell me, please, is someone going to fix this particular BugFeature(tm) or not? 

Comment 20

[K'Trina Medina]

Michael, I added your comments to bug 122698 as well since it is still open. 

Comment 21

[Matthias Versen [:Matti]]

The comment would be correct in bug 135137, bug 122698 handles only that mozilla
should not try to start a second instance if you run mozilla again.

bug 135137 trys to improve our profile locking (possible only read access to
other instances)

Comment 22

[Satheesh]

To the netscape and mozilla folks. 
After initially posting this issue I had I informed you guys that I could solve
this by using the mozilla script from the rpm installs or an old rh install.
Would it be possible for you to publish this script in this thread so anyone who
has a problem can resolve it?

like i said earlier the license terms are confusing to me so I wont publish the
script.

Cheers,

satheesh

Comment 23

[Tet]

Attachment: Partial workaround patch

Added a patch to the mozilla script which partially works around the problem.
It doesn't fix it however. In particular, it still doesn't help me, as I need
to start Mozilla on two different screens (:0.0 and :0.1).

Comment 24

[Tet]

I just found an interesting new variant on why my patch is insufficient
as a long term fix. Last night I was doing some work. I had Mozilla up
on my home machine, and I was logged into my work machine via ssh. On
trying to start Mozilla on my work machine (and display it back to my
home X display), the patched mozilla startup script detected an existing
Mozilla instance on that display, and launched a new window, despite the
fact that they're on different machines, and hence the profiles couldn't
possibly clash. Yes, I know exactly why it happened, but I'm just pointing
out that any solution needs to account for this situation...

Comment 25

[Margaret Chan]

Sorry that I have not followed this profile locking thread earlier.  Can someone
tell me whether this profile locking is per user or per system?  In our
environment, it is a very common practice that one has a browser up on one
system (leave it running and have screen locked), and bring up another instance
on another system.  They DO have to access the same profile though because the
profile is in the home directory where you can access anywhere within the
network.  Is this profile locking feature disallowing that?  We can do that
before even with Netscape 4.7x.  I am a little confused here.  Thanks.

Comment 26

[Andrew Schultz]

Comment on attachment 88111 [details] [diff] [review]
Partial workaround patch

the patch in bug 122698 is a more complete implementation of this (handles
mail, URLs, etc)

Comment 27

[Andrew Schultz]

having xremote better handle profiles is bug 151909.
Also, one instance of Mozilla cannot run on multiple displays (0:0 and 0:1)

> In bug 122698, Blizzard implies that mozilla-xremote-client already knows
> how to handle different displays. In practice, though, it doesn't seem to.

if you do

DISPLAY=:1
export DISPLAY
mozilla &
mozilla-xremote-client 'ping()'

that should work.  Mozilla cannot "search" across all possible displays because
such a list of "possible" displays does not exist.