We have a stop gap solution of setting: security.fileuri.strict_origin_policy : false This caused bug 424571.

Hmm. Did the talos boxes use to not prompt because the profile already has privileges granted?

Yes - the profile already has the privileges granted. Is there something else that I need to do to be in line with the new security requirements? I've been fiddling around with moving the quit.js file to be in the directory that it is being called from, but that doesn't seem to be enough to get around the security dialog.

This should be working... What are the file:// paths involved and what is the pref in the profile?

In the profile I have the following: user_pref("capability.principal.codebase.p0.granted", "UniversalPreferencesWrite UniversalXPConnect UniversalPreferencesRead"); user_pref("capability.principal.codebase.p0.id", "file://"); user_pref("capability.principal.codebase.p0.subjectName", ""); The first thing that I hit is with file://c:/mozilla/testing/performance/talos/getInfo.html It calls quit.js and raises the security dialog.

I suspect you want to change the "file://" thing to the actual file URI to your file. And we might want a separate bug on CAPS to change GetPrincipalDomainOrigin() to special-case file:// URIs... Otherwise the message in the dialog is not useful (it's just saying that something at "file://" wants privileges, right?).

I'll give your suggestion a try, but if that ends up being the solution then I'm going to have some trouble implementing it - since the location of the various test files that I run vary depending upon platform and allocation. And yes, the error message dialog is not particularly informative.

From my tests it looks like this can all be avoided by having the few tests that currently operate through file:// go through http://localhost (since we always have a local web server on test machines this works out of the box). Standalone talos code would have to have the security.fileuri.strict_origin_policy set to false, though - since it is set up currently to have everything run through file:// load. Would this be an acceptable solution?

I think just flipping the strict origin pref for talos (either standalone, or in general) is just fine. dveditz, any thoughts?

I filed bug 425880 on the CAPS changes I think we need.

From my reading of the bug it is okay to go ahead with simply adding the security setting security.fileuri.strict_origin_policy/false to the talos configs (production, stage and try talos).

Checked in attachement #1. This won't require any buildbot reconfigs as we already have this preference set for active talos machines as a means of sidestepping the problem, this just gets the contents of cvs lined up with what we are actually running.

Just noticed that I missed setting this for the standard config file included in the mozilla/testing/performance/talos directory.

Checking in sample.config; /cvsroot/mozilla/testing/performance/talos/sample.config,v <-- sample.config new revision: 1.14; previous revision: 1.13 done I've also updated standalone talos to use the setting: http://wiki.mozilla.org/StandaloneTalos I think that that is all the currently used config files. That fixes the bug - we can reopen if we determine that we would prefer not to have the setting and would like to find another solution.