Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing |
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: | P2 | 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
john.marmion
2002-07-10 14:18:52 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 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. Created attachment 2271 [details]
proposed patch to support OOo access to mozilla profile
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 John, assigning this to you - please to not change an issue status from "new" to "started" without changing the owner, too. Thanks :) Frank The new mozilla packages for all 4 platforms and are checked into the trunk. marking this bug as fixed. *** Issue 7480 has been marked as a duplicate of this issue. *** Marking the bug as VERIFIED. The patch works well in current component packages, thanks to John. marking this issue closed change subcomponent to 'none' |