337046 - profile support

Status: RESOLVED DUPLICATE of bug 323231

(Core Graveyard :: Java to XPCOM Bridge, defect)

Description

[Michal Ceresna]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.2) Gecko/20060419 Fedora/1.5.0.2-1.2.fc5 Firefox/1.5.0.2 pango-text
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.2) Gecko/20060419 Fedora/1.5.0.2-1.2.fc5 Firefox/1.5.0.2 pango-text

this patch adds profile support.

A testcase is e.g. to load http://news.com in the 
1.9 branch. without profile support it crashes.

Reproducible: Always

Comment 1

[Michal Ceresna]

Attachment: profile support

Comment 2

[jhp (no longer active)]

I don't agree with this patch.  First, this bug should be duped to bug 323231.  I think we should expose the methods |XRE_LockProfileDirectory()| and |XRE_NotifyProfile()| for use by Java apps.  That way, the Java developer can decide whether to use a profile or not, and how to select the profile directory.

Also, the code here seems to be wrong.  According to the docs (http://lxr.mozilla.org/mozilla/source/toolkit/xre/nsXULAppAPI.h#275), |XRE_NotifyProfile()| should be called after |XRE_InitEmbedding()|.

So I'm going to dupe this to bug 323231.  We should just expose the methods |Mozilla.lockProfileDirectory()| and |Mozilla.notifyProfile()|, and let the logic be handled by the Java app.

*** This bug has been marked as a duplicate of 323231 ***