See testcase, which asks for enhanced privileges. To reproduce: - Download testcase to your computer - Open testcase, Check the "Remember this decision" checkbox and press the "Allow" button. - Close Firefox and reopen it with the same testcase Expected result: - No enhanced privileges prompt should be shown, the script should get the enhanced privileges automatically. Actual result - Enhanced privileges prompt is shown again. This regressed between 2008-03-22 and 2008-03-23, I think a regression from bug 402983.

This is very annoying for me.

I think bug 425880 is the fix for this.

While we need to fix this, bug 425880 has been minused. This is something we can take in a dot release. wanted1.9.0.x+

Even putting this: user_pref("capability.principal.codebase.p0.granted", "UniversalXPConnect UniversalBrowserWrite UniversalBrowserRead"); user_pref("capability.principal.codebase.p0.id", "file:///"); in my user.js file doesn't seem to work :(

I use tiddlywiki for my personal notes, and this prompt has been coming up every session the first time I save any changes. It would be great if somebody could find time to address this.

The workaround for this is to manually edit "capability.principal.codebase.XXX.id" to the URL of the file you want to use, like user_pref("capability.principal.codebase.p0.id", "file:///C:/test.html");

I'm experiencing this bug in "Firefox 3.5 Preview" for Linux. It did not exist in the 3.0x series.

Perhaps in Linux, but in Windows XP, the problem exists on the 3.0x series too (I should know, I'm a tiddlywiki user too). At certain time in the past I hadn't this problem, but I'm not sure if it was with 2.0 series, or extended later with the first versions 3. If I had to guess, in some point to address the important concerns pointed in the bug 425880, someone tweaked the policy related with the "domain" file:// in a way to have strict per-file permissions (http://www.mozilla.org/projects/security/components/per-file.html), but didn't correctly changed the code that ask us to grant or deny permissions, to use the file full name instead of the domain. Somehow, the grant permissions issued works during a session but the name presented in the dialog is "file://", and that was what is saved to the prefs.js and later read in restarts to no effect. A side effect of all this unless we tweak manually the prefs.js, is the accumulation of garbage entries there which doesn't do anything. Last time I checked and clean mine, had 150 "capability.principal.codebase.#" groups with id "file://". I suppose this eats memory resources and slows down FF. My impression is that the Tiddlywiki community is becoming huge, so this might be a problem with more impact than we might think

What does the Tiddlywiki community do on non-Mozilla browsers that don't have "enhanced privileges"? Whatever that is they will have to do it on Mozilla browsers eventually because the signed-code enhanced privilege stuff is going to be ripped out post Firefox 3.5

TiddlyWiki has work-rounds for other browsers and contexts, which in the case of Webkit an Opera involves downloading a separate signed Java applet which the user has to download and accept the certificate. This approach spoils the "single file" story, so we generally advocate users use Firefox for TiddlyWiki, and a significantly large number of people do use TiddlyWiki in Firefox. We assembled a paper for the W3C Device Access workshop on TiddlyWiki which you may find useful background: http://www.w3.org/2008/security-ws/papers/osmosoft.html I wondered if you had information on the Firefox roadmap and more details of the ripping out of "enhanced privilege so we can prepare for that event. Ideally it would happen after support for the W3C file API: http://dev.w3.org/2006/webapi/FileUpload/publish/FileAPI.html

These enhanced privileges prompts don't exist anymore, so I'm marking this bug invalid.