Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing
|Summary:||Mozilla 1.0 does not support concurrent multiple versions using same profile|
|Status:||CLOSED FIXED||QA Contact:||issues@dba <issues>|
|Priority:||P2||CC:||issues, sean.gao, stx123|
|Issue Type:||DEFECT||Latest Confirmation in:||---|
|Issue Depends on:|
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'