In bug 503498 I have written a test which checks the default bookmarks for a fresh profile. The test works fine for en-US builds but breaks for localized builds. The reason is that some of the bookmarks are choosen from the en-US version. Mikeal, how do you create a fresh profile? Do you copy any files from a default folder or is it done by the profile manager of Firefox?

We copy the defaults/profile directory that applications use for generating new profiles. Is there some kind of localized location for a localized profile? Or some kinds of steps that Firefox takes after copying the default in order to localize it?

That sounds weird. Why are we doing this? Why can't we let the profile manager do this work? That would be the right way to go. Or do we have to prepare the profile in some way?

You can't silently call the profile manager like this, and the profile manager will only build profiles by name that are added to whole local system, you can't tell it to build one in /tmp that's gonna get removed when we're done. We do other things to the profile after it's been created, we install plugins (again, by extracting/copying them in to the plugins dir) and we set and preferences defined in the Profile class by writing a user.js file in the profile.

Can you point me to the code we are using? Is it in mozrunner, jsbridge, or mozmill? Quiet a bit confusing all those stuff. :) I would like to have a look at.

It's all in the mozrunner.Profile class: http://code.google.com/p/mozrunner/source/browse/trunk/mozrunner/__init__.py#163

(In reply to comment #3) > You can't silently call the profile manager like this, and the profile manager > will only build profiles by name that are added to whole local system, you > can't tell it to build one in /tmp that's gonna get removed when we're done. > You can do this by calling -CreateProfile /tmp The only caveat to that is that the directory structure you have to give it must be a native directory structure and the current user must have access to it. > we set preferences defined in the Profile class by writing a user.js file in the > profile. You'd still have to do this even if you went and created your own profile through the profile manager API as it has no way to specify defaults for the profile. Henrik, FWIW mochitest and reftest driver code does the same thing with recreating temporary profiles for use and setting their preferences.

> You can do this by calling -CreateProfile /tmp > The only caveat to that is that the directory structure you have to give it > must be a native directory structure and the current user must have access to > it. I wish I would have known about this a year ago :) what does "native directory structure" mean?

Mikeal, I believe the Python script below will be very helpful for our needs. Looks like we already have everything in our code base: http://mxr.mozilla.org/mozilla-central/source/testing/tools/profiles/createTestingProfile.py

This only does a little of what mozrunner does. I think it would be great to use the -CreateProfile stuff but it's a large change to the code base and would necessitate a mozrunner 1.1 release. When i have some time I'll move to -CreateProfile but this code isn't really that helpful because it's fairly different structurally and doesn't support the same featureset.

Also, i just noticed that this does not actually create a profile in a specific path, it creates a profile by name which is then attached to the profile manager. This isn't acceptable for mozrunner and it needs to build profiles in /tmp and not mess with the locally installed registry of profiles. Does anyone have a link to docs/code that uses -CreateProfile to create a profile in a specific location that is not added to the profile registry?

Mmh CreateProfile has two parameters. The second one is for the path. But you are right. Having it added to the profile manager isn't what we want. Mikeal, why don't you always copy the default profile from within the given application folder? That's the one we need. I cannot really follow the code so please help me. I have the German version located at "/Applications/Firefox 3.5.1 de.app". Where do you look for the default profile? In "/Applications/Firefox.app"?

On Linux and windows the default profile isn't in the application folder, on Mac we do have support for this. If you only pass the .app dir as the binary path it will work.

On all platforms the default profile is under the application folder. Exactly at defaults/profile. That's also the place where the localized bookmarks.html is located. So using any other folder is the wrong way because it will cause the profile initialization be based not on the applications locale.

For a really bad side-effect with CreateProfile see bug 509145. Mikeal, if we can update mozrunner to grab the correct default profile data it should be easier to do. Would you need some more information?

As what I have seen today this is a more global problem and doesn't only affect l10n restart tests. When you have a fresh install of Windows and you do not install Firefox but a Shiretoko build only, Mozmill will not work from the command line because it cannot find the default profile. This is bad because it will definitely fail when we wanna run it on the build system. We really have to use the default profile from the build which we run when starting Mozmill from the command line. We cannot rely on any other folder on the system.

Some of this sounds a bit like http://code.google.com/p/mozrunner/issues/detail?id=8 For Thunderbird we actually use -CreateProfile in the create_new_profile step, and ignore default profile argument etc in our test harness. http://mxr.mozilla.org/comm-central/source/mail/test/mozmill/runtest.py

(In reply to comment #16) > Some of this sounds a bit like > http://code.google.com/p/mozrunner/issues/detail?id=8 It's exactly this reported problem. The localization part is only a side-effect when having a branded build installed. If not you will see the exact same error: Exception: Could not locate default profile, please set. > For Thunderbird we actually use -CreateProfile in the create_new_profile step, > and ignore default profile argument etc in our test harness. > > http://mxr.mozilla.org/comm-central/source/mail/test/mozmill/runtest.py Doesn't it add the profile to the list of profiles in the profile manager? How do you get rid of these temporary profiles?

(In reply to comment #17) > > For Thunderbird we actually use -CreateProfile in the create_new_profile step, > > and ignore default profile argument etc in our test harness. > > > > http://mxr.mozilla.org/comm-central/source/mail/test/mozmill/runtest.py > > Doesn't it add the profile to the list of profiles in the profile manager? How > do you get rid of these temporary profiles? Yes it does add it to profile manager. Worst case, that's just one additional profile listed. What I didn't quite explain is that we have one profile location and one profile name for the automated mozmill tests. What we do is: 1) rm -r <profile location> (if it exists) 2) -CreateProfile <name> <location> 3) Run test suite(s). We leave the profile at the end of the test in case there's been an issue and the developer wishes to try further things with the profile that was used in the test. Using the same name for the profile actually means that however many times you run it, you end up with only one entry in profile manager - so we've just ignored the one extra entry (no-one has complained so far).

(In reply to comment #18) > (In reply to comment #17) This is what I mentioned to Mikeal when this issue first came up. I really don't see the need for any other work around. I think we should do what Mark & Thunderbird people are doing. Who cares if you have a bunch of profiles? If "don't ask at startup" is checked, (which it is for all default installs) then other people will never be aware of the new profile.

(In reply to comment #19) > Who cares if you have a bunch of profiles? If "don't ask at startup" is > checked, (which it is for all default installs) then other people will never be > aware of the new profile. Sounds good. The only thing we have to take care of are mozmill-restart tests. We definitely have to remove the content of the existing testing profile before we create a new profile for the next test at the same location. Otherwise old files could interfere the current test run.

According to Clint there is a way to do this without adding the new profile to the profile manager. If that's the case then I'm definitely for it. Most people don't keep multiple profiles on their computer and if we add it to the profile manager the next time they launch they'll be annoyed by seeing the profile manager pop up. Plus I'd like to step on the local system install as little as possible. Even if we have the remove code at the end we run in to conditions where mozmill gets killed mid cycle and will leave this profile around. If it's not possible to create a profile without it being added to the profile manager there are 2 other options. 1) Immediately after creating the profile, edit whatever file the profile manager lists it's know profiles in and remove the entry 2) Immediately after creating the profile copy it again to a tmp directory and tell the profile manager to remove the other profile

(In reply to comment #21) > According to Clint there is a way to do this without adding the new profile to > the profile manager. If that's the case then I'm definitely for it. Benjamin, can you help us out? Do we have a way to do this?

I don't understand what this discussion is about. If you create an empty directory (in /tmp/foo for example) and then launch firefox with -profile /tmp/foo it should have the correct default bookmarks. Are you saying it doesn't? Or that you're doing something different?

Thanks Benjamin. Given your reply we would be able to stick at the current implementation but shouldn't copy any files under defaults/profile to the new profile. Everything will happen by Firefox itself. So the only thing we have to prepare are the extensions and the user.js. See comment 5 for the current version of our script. (In reply to comment #23) > firefox with -profile /tmp/foo it should have the correct default bookmarks. > Are you saying it doesn't? Or that you're doing something different? Correct. I get mixed content. But I hardly believe it happens because we are using the wrong Firefox version to prepare the profile.

Ok, this is a pretty large reverse-incompatible change so I did the work in a branch. Thanks to Clint for working out the process code. http://github.com/mikeal/mozrunner/tree/createprofile Once I'm convinced this code is working and doesn't break anything I'll merge it in to master. Also, I think Windmill will probably finally do mozrunner2 integration for it's 1.5 release. This code will make the Windmill Firefox configuration stuff significantly easier.

Clint, it looks like that your patch caused that the profile is created twice: mozmill -b /Applications/Shiretoko.de.app -t test/firefox/restartTests/testDefaultBookmarks/ --show-errors Success: created profile '2bf0c916-b1ae-11de-b8f9-002332b130e8 /var/folders/w2/w2myuXRLE1q1Ex7puQAPYk+++TI/-Tmp-/tmpFqJRKM.mozrunner' at '/var/folders/w2/w2myuXRLE1q1Ex7puQAPYk+++TI/-Tmp-/tmpFqJRKM.mozrunner/prefs.js' Success: created profile '2bf9d66e-b1ae-11de-b8f9-002332b130e8 /var/folders/w2/w2myuXRLE1q1Ex7puQAPYk+++TI/-Tmp-/tmpTMXUd0.mozrunner' at '/var/folders/w2/w2myuXRLE1q1Ex7puQAPYk+++TI/-Tmp-/tmpTMXUd0.mozrunner/prefs.js' Or do we have another bug and always call create profile twice? That could be the reason why profile folders aren't removed because we only take care of one of those two.

(In reply to comment #25) > Thanks to Clint for working out the process code.> > http://github.com/mikeal/mozrunner/tree/createprofile That looks great. There is only one question so far. Can we get rid of all the uncommented code too? It's not needed anymore.

merged to master http://github.com/mikeal/mozrunner/commits/master

Works fine so far with: http://github.com/mikeal/mozrunner/commit/e11301d26ae287de42870d839bf8efe984c7b39b We only have to get the removal of profiles working. Verified fixed.