Files from defaults/profile are missing in new profiles when packaged in omni.ja

RESOLVED WONTFIX

Status

RESOLVED WONTFIX
4 years ago
2 months ago

People

(Reporter: mozbugs, Unassigned)

Tracking

(Depends on: 1 bug)

Details

Attachments

(2 attachments, 1 obsolete attachment)

(Reporter)

Description

4 years ago
User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/39.0.2171.71 Safari/537.36

Steps to reproduce:

I am trying to add a file to the defaults/profile folder so that it becomes a part of every profile that is created. To do this, I am adding the file name to im/app/profile/Makefile (I also add the file to this directory) and im/installer/package-manifest.


Actual results:

The file is copied to the obj-*/dist/bin/defaults/profile folder, along with mimeTypes.rdf, localstore.rdf and prefs.js. The package-manifest also contains these file names. However, on packaging (using mach package), the profile folder is completely excluded from the package and no file is copied, neither the file I created nor the files mentioned above.


Expected results:

The defaults/profile folder and all files in it should have been copied to the defaults folder in the package.

Comment 1

4 years ago
Created attachment 8536571 [details] [diff] [review]
Use flags for defaults/profile and drop defaults/profile/US

Try this and see if it helps please!
Attachment #8536571 - Flags: feedback?(sukhbir.in)

Updated

4 years ago
Status: UNCONFIRMED → NEW
Ever confirmed: true
Whiteboard: [1.6-blocking]
Isn't this included in omni.ja these days?

Comment 3

4 years ago
(In reply to Florian Quèze [:florian] [:flo] from comment #2)
> Isn't this included in omni.ja these days?

Possibly, but it's still a bug. I have confirmed that a new profile created from a local build differs before and after packaging, in that after packaging the only file added is times.json.
(Reporter)

Comment 4

4 years ago
Created attachment 8536616 [details] [diff] [review]
firstfix.diff

first attempt at profilefix.diff
(Reporter)

Comment 5

4 years ago
(In reply to aleth [:aleth] from comment #1)
> Created attachment 8536571 [details] [diff] [review]
> profilefix.diff
> 
> Try this and see if it helps please!

So I tried and I think the issue persists. I have attached the diff of comm-central (firstfix.diff) to be sure.

(The "testing" file is there in obj-*/dist/bin again, along with the other files. It doesn't get copied to the package though.)

Comment 6

4 years ago
Comment on attachment 8536571 [details] [diff] [review]
Use flags for defaults/profile and drop defaults/profile/US

Review of attachment 8536571 [details] [diff] [review]:
-----------------------------------------------------------------

We should take this port to be in sync with TB, even though it doesn't fix this bug.
Attachment #8536571 - Flags: feedback?(sukhbir.in) → review?(florian)

Comment 7

4 years ago
(In reply to sukhbir.in from comment #5)
> (The "testing" file is there in obj-*/dist/bin again, along with the other
> files. It doesn't get copied to the package though.)

This isn't correct. The files are packaged, but in omni.ja. The problem is that on creation of a new profile, they are not copied into it.

Updated

4 years ago
Summary: Unable to package the defaults/profile folder → Files from defaults/profile are missing in new profiles when packaged in omni.ja

Updated

4 years ago
Attachment #8536616 - Attachment is obsolete: true

Updated

4 years ago
Attachment #8536571 - Attachment description: profilefix.diff → Use flags for defaults/profile and drop defaults/profile/US

Updated

4 years ago
Depends on: 1111670
(Reporter)

Comment 8

4 years ago
(In reply to aleth [:aleth] from comment #7)
> (In reply to sukhbir.in from comment #5)
> > (The "testing" file is there in obj-*/dist/bin again, along with the other
> > files. It doesn't get copied to the package though.)
> 
> This isn't correct. The files are packaged, but in omni.ja. The problem is
> that on creation of a new profile, they are not copied into it.

Ah yes, that's true. Just confirmed. Sorry, I have overlooked this. The "testing" file is indeed in omni.ja.
No longer depends on: 1111670

Comment 9

4 years ago
(In reply to sukhbir.in from comment #8)

Could you please put back the dependency you removed? ;)
(Reporter)

Updated

4 years ago
Depends on: 1111670
Attachment #8536571 - Flags: review?(florian) → review+

Comment 10

4 years ago
From bsmedberg's comments on the platform bug, it appears support for adding files in defaults/profile is no longer officially supported. However, unless that bug sees some action soon, it's likely nothing much will change for now.

So I suggest you add the files to NON_OMNIJAR_FILES in the makefile, that should make the profile initializer find them.
(Reporter)

Comment 11

4 years ago
(In reply to aleth [:aleth] from comment #10)
> From bsmedberg's comments on the platform bug, it appears support for adding
> files in defaults/profile is no longer officially supported. However, unless
> that bug sees some action soon, it's likely nothing much will change for now.
> 
> So I suggest you add the files to NON_OMNIJAR_FILES in the makefile, that
> should make the profile initializer find them.

Just to make it clear, should I be adding the files to im/app/profile/ (and the makefile in that directory), and then reference them using NON_OMNIJAR_FILES in im/installer/Makefile?

Comment 12

4 years ago
(In reply to sukhbir.in from comment #11)
> (In reply to aleth [:aleth] from comment #10)
> > From bsmedberg's comments on the platform bug, it appears support for adding
> > files in defaults/profile is no longer officially supported. However, unless
> > that bug sees some action soon, it's likely nothing much will change for now.
> > 
> > So I suggest you add the files to NON_OMNIJAR_FILES in the makefile, that
> > should make the profile initializer find them.
> 
> Just to make it clear, should I be adding the files to im/app/profile/ (and
> the makefile in that directory), and then reference them using
> NON_OMNIJAR_FILES in im/installer/Makefile?

I guess you have to add the file normally to the im/app/profile makefile, and then in the im/installer makefile do something like 

NON_OMNIJAR_FILES = \
    defaults/profile/yourfile \
    $(NULL)

Just experiment ;)
(Reporter)

Comment 13

4 years ago
Created attachment 8537862 [details] [diff] [review]
Patch to copy a file to defaults/profile during packaging

(In reply to aleth [:aleth] from comment #12)
> (In reply to sukhbir.in from comment #11)
> > (In reply to aleth [:aleth] from comment #10)
> > > From bsmedberg's comments on the platform bug, it appears support for adding
> > > files in defaults/profile is no longer officially supported. However, unless
> > > that bug sees some action soon, it's likely nothing much will change for now.
> > > 
> > > So I suggest you add the files to NON_OMNIJAR_FILES in the makefile, that
> > > should make the profile initializer find them.
> > 
> > Just to make it clear, should I be adding the files to im/app/profile/ (and
> > the makefile in that directory), and then reference them using
> > NON_OMNIJAR_FILES in im/installer/Makefile?
> 
> I guess you have to add the file normally to the im/app/profile makefile,
> and then in the im/installer makefile do something like 
> 
> NON_OMNIJAR_FILES = \
>     defaults/profile/yourfile \
>     $(NULL)
> 
> Just experiment ;)

Thanks, that worked. I have attached a patch with a sample file called "testing" which is included in defaults/profile and therefore is copied to any profile that is created.

Updated

4 years ago
Whiteboard: [1.6-blocking]
Is this "fixed" then or no?

Comment 16

4 years ago
(In reply to Patrick Cloke [:clokep] from comment #15)
> Is this "fixed" then or no?

No. We could use something similar to comment 12 for the files which are nominally packaged in defaults/profile, but Firefox doesn't do this either. According to the discussion in the linked bug, this is dead code and if it gets removed that workaround will also likely break.
On the behalf of Florian:
Closing bugs related to the Instantbird UI as WONTFIX, as the development of the standalone chat client Instantbird has stopped. Instantbird users are encouraged to migrate to Thunderbird. The user interface of instant messaging in Thunderbird will feel familiar, as the Thunderbird IM support started as a fork of Instantbird.
Status: NEW → RESOLVED
Last Resolved: 2 months ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.