Issue 6391 - Mozilla 1.0 does not support concurrent multiple versions using same profile
Summary: Mozilla 1.0 does not support concurrent multiple versions using same profile
Status: CLOSED FIXED
Alias: None
Product: Base
Classification: Application
Component: code (show other issues)
Version: OOo 1.0.1
Hardware: All All
: P2 Trivial (vote)
Target Milestone: ---
Assignee: john.marmion
QA Contact: issues@dba
URL:
Keywords: oooqa
: 7480 (view as issue list)
Depends on:
Blocks: 5812
  Show dependency tree
 
Reported: 2002-07-10 14:18 UTC by john.marmion
Modified: 2006-05-31 14:29 UTC (History)
3 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---


Attachments
proposed patch to support OOo access to mozilla profile (1.59 KB, patch)
2002-07-17 10:39 UTC, john.marmion
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this issue.
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'