756131 - API for creating default profiles for webapps

Status: RESOLVED FIXED

(Toolkit :: General, defect)

Description

[Olli Pettay [:smaug][[e-mail]]]

Attachment: patch

To be able to pre-populate webapps appcache, we need to be able to create the profile during installation.
If the following is run in FF, FF's default profile ends up to $HOME/.mozilla/foobarapp/{salt}.default
If "Mozilla" is not use, it will be in $HOME/.foobarapp/{salt}.default

var currentDefaultProfile = Components.classes["@mozilla.org/file/directory_service;1"].getService(Components.interfaces.nsIProperties).get("profDef", Components.interfaces.nsIFile);
var ts = Components.classes["@mozilla.org/toolkit/profile-service;1"].getService(Components.interfaces.nsIToolkitProfileService);
ts.createDefaultProfileForApp("FooBarApp", "Mozilla", currentDefaultProfile);

I just realized I'm missing still profile.ini handling.

Comment 1

[Olli Pettay [:smaug][[e-mail]]]

Attachment: +profile.ini creation

Comment 2

[Olli Pettay [:smaug][[e-mail]]]

https://tbpl.mozilla.org/?tree=Try&rev=e8ba9b56835d
Hopefully it compiles on Windows so that I can try creating profile for a web app before launching it.

Comment 3

[Olli Pettay [:smaug][[e-mail]]]

Ah, webapps do something a bit strange.
profiles.ini is in directory Foo, but profile in Foo/Profiles/salt.default

Comment 4

[Olli Pettay [:smaug][[e-mail]]]

Er, my mistake.
Doesn't help that I can use only linux for development :)

Comment 5

[Olli Pettay [:smaug][[e-mail]]]

Attachment: v3

Comment 6

[Olli Pettay [:smaug][[e-mail]]]

Attachment: v4

Comment 7

[Olli Pettay [:smaug][[e-mail]]]

https://tbpl.mozilla.org/?tree=Try&rev=b332f63d0ea5

Comment 8

[:Felipe Gomes (needinfo for replies!)]

Comment on attachment 624946 [details] [diff] [review]
v4

I tested v4 of the patch using that try build. It created the Path=Profiles/asfda.default correctly in the .ini file, and created the folder at appname/Profiles/asfda.default as expected, however the folder it created is empty

Comment 9

[Olli Pettay [:smaug][[e-mail]]]

did you pass the 3rd parameter to the method?

Comment 10

[Olli Pettay [:smaug][[e-mail]]]

(Since I thought the v3 did copy the default profile files even on Windows, and v4 shouldn't change
that, only profiles.ini handling.)

Comment 11

[Olli Pettay [:smaug][[e-mail]]]

Ok, I get the same problem :(

Comment 12

[Olli Pettay [:smaug][[e-mail]]]

How strange. If I change the #ifdef which creates Profiles directory, I still get the
right profile on Linux.

Comment 13

[Olli Pettay [:smaug][[e-mail]]]

Attachment: v5

Somewhat random guess. Ensure that Profiles directory exists before copying
anything under it.

https://tbpl.mozilla.org/?tree=Try&rev=6c6d1e49f9b9

Comment 14

[Olli Pettay [:smaug][[e-mail]]]

Comment on attachment 625115 [details] [diff] [review]
v5

this doesn't help. So v4 is still the best one. Need to figure out why
right files aren't copied.
Is rv = profileDefaultsDir->CopyTo(profileDirParent, profileDirName);
in nsToolkitProfileService not executed or does it fail

Comment 15

[Olli Pettay [:smaug][[e-mail]]]

Felipe, or anyone with Windows dev environment, I could need some help here.

Comment 16

[:Felipe Gomes (needinfo for replies!)]

Smaug: does this seem like a timing issue and the patch v3 when I tried just worked by luck?  or is there something that changed between v3 and v4 that could have caused it to fail?
I'll debug it soon

Comment 17

[:Felipe Gomes (needinfo for replies!)]

ooh wait I second, when I build the patch myself (v4) it works.. when I use the try build it didn't (I'll try it again)..  maybe this is a packaging issue

Comment 18

[:Felipe Gomes (needinfo for replies!)]

indeed, currentDefaultProfile.exists() is false on a packaged build

Comment 19

[Olli Pettay [:smaug][[e-mail]]]

Bizarre. But ok, so Components.classes["@mozilla.org/file/directory_service;1"].getService(Components.interfaces.nsIProperties).get("profDef", Components.interfaces.nsIFile); is wrong.

Comment 20

[Olli Pettay [:smaug][[e-mail]]]

Does default profile handling work with packaged builds at all?
Need to test.

Comment 21

[Olli Pettay [:smaug][[e-mail]]]

That is indeed true, at least on linux. Files don't get created when profile is created.
When using own build, the files are created when the profile is.

Comment 22

[Olli Pettay [:smaug][[e-mail]]]

Comment on attachment 624946 [details] [diff] [review]
v4

I'm not going to fix that behavior in this bug.
This should give similar to current webapp profiles when the
2 latter parameters are omitted.

Comment 23

[Olli Pettay [:smaug][[e-mail]]]

...and if webapps need a default profile, some new, non-packaged stuff can be added to Firefox installation.

Comment 24

[Olli Pettay [:smaug][[e-mail]]]

Comment on attachment 624946 [details] [diff] [review]
v4

But I want to change the API :/
The method should give two nsIFiles out, the rootdir and localdir.
I believe appCache stores data in localDir

Comment 25

[Olli Pettay [:smaug][[e-mail]]]

Attachment: v6, reuse nsIToolkitProfile

This is pretty flexible. The appname and optional vendor name are passed to
nsXREDirProvider so that right kind of directory hierarchy can be created.
aProfileDefaultsDir lets one to define where the "template" for the profile is.

https://tbpl.mozilla.org/?tree=Try&rev=b0097709a637

Comment 26

[Benjamin Smedberg]

Comment on attachment 625426 [details] [diff] [review]
v6, reuse nsIToolkitProfile

Since webrt overrides the normal system in nsXREAppData: http://mxr.mozilla.org/mozilla-central/source/webapprt/win/webapprt.cpp#289

So in order to do this with the same logic as nsXREDirProvider::AppendProfilePath you really need appname, vendor, and "profile" from nsXREAppData, and vendor name really shouldn't be optional in the IDL. I think the rest of the patch is fine, but I'd like some comments in nsXREDirProvider.h explaining why we need to pass in directories to the methods like GetUserDataDirectory and such.

Comment 27

[Olli Pettay [:smaug][[e-mail]]]

(In reply to Benjamin Smedberg  [:bsmedberg] from comment #26)
> Comment on attachment 625426 [details] [diff] [review]
> v6, reuse nsIToolkitProfile
> 
> Since webrt overrides the normal system in nsXREAppData:
> http://mxr.mozilla.org/mozilla-central/source/webapprt/win/webapprt.cpp#289
> 
> So in order to do this with the same logic as
> nsXREDirProvider::AppendProfilePath you really need appname, vendor, and
> "profile" from nsXREAppData, and vendor name really shouldn't be optional in
> the IDL. 
Vendor is optional in the other cases. Why not here?

Comment 28

[Benjamin Smedberg]

I think that the caller should specify it, whether it is null or a value.

Comment 29

[Olli Pettay [:smaug][[e-mail]]]

Attachment: +comments

https://tbpl.mozilla.org/?tree=Try&rev=2a0484aab586

Comment 30

[Olli Pettay [:smaug][[e-mail]]]

Attachment: +compilation fixes

Maybe this even compiles on platforms I can't build on.

https://tbpl.mozilla.org/?tree=Try&rev=03b29673813f

Comment 31

[Benjamin Smedberg]

Comment on attachment 626192 [details] [diff] [review]
+compilation fixes

+  nsresult rv = GetUserDataDirectory((nsILocalFile**)(nsIFile**)
+                                      getter_AddRefs(file),

Darktrojan is fixing most of this in bug 749930, but if you can just change GetUserDataDirectory to nsIFile while you're here this will avoid the terrible terrible casting.

Comment 32

[Olli Pettay [:smaug][[e-mail]]]

IIRC I tried that but I would have had to change plenty of other code too.

Comment 33

[Olli Pettay [:smaug][[e-mail]]]

https://hg.mozilla.org/mozilla-central/rev/4f66e59eaa77