Issue 6391

Summary:

Mozilla 1.0 does not support concurrent multiple versions using same profile

Product:

Base

Reporter:

john.marmion

Component:

code

Assignee:

john.marmion

Status:

CLOSED FIXED

QA Contact:

issues@dba <issues>

Severity:

Trivial

Priority:

CC:

issues, sean.gao, stx123

Version:

OOo 1.0.1

Keywords:

oooqa

Target Milestone:

---

Hardware:

All

OS:

All

Issue Type:

DEFECT

Latest Confirmation in:

---

Developer Difficulty:

---

Issue Depends on:

Issue Blocks:

5812

Attachments:

Description	Flags
proposed patch to support OOo access to mozilla profile	none

Description john.marmion 2002-07-10 14:18:52 UTC

OOo 1.0.1 now supports integration with Mozilla 1.0 Address Book . Mozilla rc3
and thus mozilla 1.0 introduced the concept of profile locking.  Thus it is no
longer possible to fire up a second version of mozilla using the same profile.
Users are asked to choose/create a different profile.  This 
strategy is discussed in :

http://bugzilla.mozilla.org/show_bugs.cgi?id=76431

This strategy is a departure from netscape 4.x which supported a readonly access
when a second version was launched.

This has some serious implications for OOo. Ooo integrates with mozilla in two
ways:

1. Mozilla Address Book 
2. External Mozilla Mailer

The effect of this issue can be seen in the following ways:

1. Thus if Mozilla is already running and attempts are made to access a Mozilla
DataSource from within OOo, then OOo will fail siilently and default to the
Personal and Collected Address Books only and even worse, will return no data
from queries. If on the other hand, OOo is running, then attempts to start
mozilla will result in the user been forced to choose/create a different
profile.

2. OOo also supports the integration of Mozilla as an external mail program.
Thus users can choose to send a document as an attachment in a mail by firstly
configuring Mozilla as the mailer and then by File -> Send -> Document as
E-mail.  This is a nice feature where the user is taken into the Compose Window
of Moizlla and the file is already attached tothe mail. Thus if mozilla is
already running and an attempt  is made to fire up the mozilla mailer from
within OOo, the user will be confronted by the same choose/create another
profile. And likewise in the reverse scenario. I have observed this behaviour on
UNIX systems only. On Windoze, mozilla apperas to be smart enough to delegate to
an already running mozilla.

So possible solutions:

We could opt for an OOo profile for Mozilla that we would always default to. But
this would involve us writing to mozilla profiles. All our integration work
to-date has a read-only access to it. Looking at the discussion around Bugzilla
#76431, it may seem unlikely that we can persuade mozilla to modify this. But if
this is so, then we are left with no alternative but to patch mozilla.

Comment 1 john.marmion 2002-07-16 15:53:30 UTC

Searching through the Mozilla BugZilla database, I came across the
following bug:

http://bugzilla.mozilla.org/show_bug.cgi?id=122698

The patch attachment to this bug appears to successfully fix the
problem that we are having with using the external mozilla mailer for
our send-as-email.  This patch simply patches the run-mozilla.sh
startup script. This patch looks like it will certainly address the
issues around (2) above and succcessfully delegates to an already
running mozilla. I tested the patch on Linux against a Mozilla 1.0
distribution.

I also came across:

http://bugzilla.mozilla.org/show_bug.cgi?id=149126

Comment 2 john.marmion 2002-07-17 10:15:45 UTC

On the Mozilla Address Book issue, the fallout from the mozilla
decision to employ profile locking has generated a lot of heat. The
original bug was:

http://bugzilla.mozilla.org/show_bug.cgi?id=76431 

Now there exists 

http://bugzilla.mozilla.org/show_bug.cgi?id=135137

This bug states "Profile data cannot be shared by multiple running
instances". This bug incorporates bug:

http://bugzilla.mozilla.org/show_bug.cgi?id=154875

which bluntly states that the "Profile fix needs to be fixed".

My opinion is that there is enough momentum for mozilla to incorporate
an ability to have some readonly shared access to the same profile. We
should get behind that and add our scenario as a further case to push
for that solution. In the meantime, I suggest that we have two
possible solutions.  

1. We disable the profile locking in our mozilla profile component.
This solution essentially gives us a read-only access to the default
mozilla profile. All our access to mozilla address books is read-only.
It does not effect how mozilla itself works. This is a relatively
straightforward patch. We are not adding a new component as we already
use the profile. The main negative issue is that we are patching
mozilla.

2. We create an "openoffice" mozilla profile and always default to
this. This involves us changing our existing read-only access to write
access. The main problem with this is that address book data is not
shared between profiles.  Having access to our "own" profile means
that the user would need to copy address book data from their default
mozilla profile to the "openoffice" profile.

I suggest that we go with (1) above as our only valid option until
this is fixed in mozilla. I will post  a patch for a review.

Comment 3 john.marmion 2002-07-17 10:39:42 UTC

Created attachment 2271 [details]
proposed patch to support OOo access to mozilla profile

Comment 4 Frank Schönheit 2002-07-17 12:50:12 UTC

John,

I quickly went over the mozilla bugs you pointed us to, and I agree
that it seems there is some momentum to change this in Mozilla. Do you
mind pursueing this in Mozilla, an add our problems to the respective
bugs, so that the Mozilla engineers can consider them when searching
for a solution?

I also agree that 1. would be the preferred way - 2. would burden the
average user with a lot of unnecessary hassle.
On the medium term, we need to convince Mozilla to provide a more
elegant mechanism, this would be a prerequisite for not shipping own
components anymore, but I think 1. is a good solution 'til then.

Frank

Comment 5 Frank Schönheit 2002-07-22 10:56:39 UTC

John, assigning this to you - please to not change an issue status
from "new" to "started" without changing the owner, too. Thanks :)
Frank

Comment 6 john.marmion 2002-07-23 17:59:36 UTC

The new mozilla packages for all 4 platforms and are checked into the
trunk.

Comment 7 john.marmion 2002-08-08 16:32:23 UTC

marking this bug as fixed.

Comment 8 Frank Schönheit 2002-09-04 07:25:52 UTC

*** Issue 7480 has been marked as a duplicate of this issue. ***

Comment 9 seangao 2002-11-04 02:39:26 UTC

Marking the bug as VERIFIED. The patch works well in current component
packages, thanks to John.

Comment 10 john.marmion 2002-11-08 13:11:53 UTC

marking this issue closed

Comment 11 hans_werner67 2004-02-02 13:03:50 UTC

change subcomponent to 'none'