435254 - 'remember this selection' not saved across FF sessions

Status: RESOLVED WONTFIX

(Core :: Security, defect)

Description

[Jonathan Belanger]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9) Gecko/2008051206 Firefox/3.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9) Gecko/2008051206 Firefox/3.0

When attempting to run a local JavaScript, I get an Internet Security dialog indicating that the script is attempting to do something that is UNSAFE.  It then gives me a check off box to 'remember this selection' and an 'Allow' and 'Deny' button.  Checking off the 'remember this selection' box and clicking on the 'Alllow' button, allows the script to continue as expected.  When I exit FF and then start it back up and attempt to run this same script, I get the dialog again.  The 'remember this selection' is ignored and should be retained across FF sessions.

Reproducible: Always

Steps to Reproduce:
1. run a script containing XMLHttpRequest using the netscape.security.PrivilegeManager.enablePrivilege("UniversalBrowserRead"); function.
2. see the dialog and click 'remember...' and 'allow.  Rerun the script as often as you'd like in the current session (without a problem).
3. Exit FF and then start a new session.
4. run the same script from step 1.  Notice the dialog is back.
Actual Results:  
I repeatedly get the Internet Security dialog for the same issue even though I selected the 'remember this selection' check box.

Expected Results:  
I expect the 'remember this selection' check box to function across FF session.  I should only ever have to see this dialog once, ever, when using this check off box.

Remember my selection.

Comment 1

[Fraser Smith]

One way to reproduce this is to download empty.html from www.tiddlywiki.com and load it in FF3.  Click "New Tiddler", enter some text and click "Done" from the Tiddler's menu.  Finally, click "Save changes" on the right sidebar.  The UNSAFE action message will appear.  Click "Remember this selection" and "Allow".

Restart FF3 and reload empty.html, repeating the test.  On "Done" or "Save Changes" the UNSAFE action message will re-appear.

Comment 2

[Mike Beltzner [:beltzner, not reading bugmail]]

I can't reproduce this with the latest nightly on OSX. What version are you using?

Comment 3

[Mike Beltzner [:beltzner, not reading bugmail]]

It's also by no means "blocker" severity, and wouldn't block the ship of Firefox 3.0 - though if we can confirm it, we might consider a security and stability fix on it.

Johnath: as an aside, the message the JS engine provides here is pretty horrible, and we might want to look into that :)

Comment 4

[Mike Beltzner [:beltzner, not reading bugmail]]

Huh. I *can* confirm this on PC, though, with the latest nightly. Is this in the right component, or is this a JS thing?

Comment 5

[Mike Beltzner [:beltzner, not reading bugmail]]

Admittedly very annoying for people doing local JS apps.

Comment 6

[Jonathan Belanger]

I'm using RC1 that is distributed from the getfirefox.com web site.  Here is the version information:

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9) Gecko/2008051206 Firefox/3.0

As for this not being a blocker or simply annoying, if a prodct presents a feature and that feature does not work then it is a blocking bug.  Either that or remove the feature.  Not being able to save security decisions from FF session to FF session is a significant bug.  What if everything you wanted to do something on your computer you had to type in your password?  Would you use that operating system?  I didn't think so.  So, I disagree that this should not block the release.

I don't generally install nightlies.  I will put RC2 up when it is available and test this out.

Comment 7

[Fraser Smith]

I'd just like to add an observation that, to me, make this bug more serious.  

We're talking as if this setting is being lost across FF3RC1 sessions and in general, that is the case, however, in the last few days, I've noticed that, it may lose the setting within the same session.

I use a TiddlyWiki variant all day and I usually open an FF3 session when I start work and leave it minimized or in the background until I need it.  I've found that, after a few hours, I can come back to the same session and once again I get presented with the same dialog, even though I had Allowed it earlier that day and clicked to remember the choice.  During this time, FF3 has been running all the time without a restart.

Comment 8

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

Can someone attach a test case?  That'll make it a lot easier to make sure it's fixed for 3.0.1.

Comment 9

[Jonathan Belanger]

This problem still persists with RC2.  I marked the Severity on this as Major because this issue is a usability problem.  I have quite a few of similar web pages to that below and I use to be able to put them all in a bookmarks folder and tell FF to open all of them into their own tab in a single click.  Now I have to go to each individual file, open it into its own tab and then click 'Allow' for each (a total of at least 3 clicks for each).  Though FF does not crash, it is effectively unusable in its current state with this problem persisting.

Here is a test case demonstrating the problem:

<html>
<head>
<script type="text/javascript">

//
// Global variables
//
var req = false;
var urlBase = new Array(
	"http://www.webshots.com/search?query=snowmobile&sortBy=most-recent&start=0");
var curReqUrl = null;

//
// This function is called to start the loading process
//
function start()
{

 //
 // If there is a native XMLHttpRequest object, use it.
 //
 if (window.XMLHttpRequest)
   netscape.security.PrivilegeManager.enablePrivilege("UniversalBrowserRead"); 
 if (req == false)
 {
  if (window.XMLHttpRequest)
  {
   try
   {
    req = new XMLHttpRequest();
   }
   catch(e)
   {
    req = false;
   }
  }

  //
  // Else, see if we have a ActiveXObject we can create.
  //
  else if (window.ActiveXObject)
  {
   try
   {
    req = new ActiveXObject("Msxml2.XMLHTTP");
   }
   catch(e)
   {
    try
    {
     req = new ActiveXObject("Microsoft.XMLHTTP");
    }
    catch(e)
    {
     req = false;
    }
   }
  }
 }

 //
 // If we created a req object, use it now.
 //
 if (req)
 {
  var url;

  url = urlBase;
  req.onreadystatechange = processReqStateChange;
  req.open("GET", url, true);
  req.send(null);
  curReqURL = url;
 }
 else
 {
  alert("Failed to create XMLHttpRequest object!");
 }
}

//
// This function is called as part of the XMLHttpRequest asynchronous processing.
//
function processReqStateChange()
{

 //
 // If we created a req object, use it now.
 //
 if (req)
 {

  //
  // We only concern ourselves when the data has been fully "loaded"
  //
  if (req.readyState == 4)
  {

   //
   // We only can load the data into the webshots frame when the status is "OK"
   //
   if (req.status == 200)
   {
    updateStatus("Test Complete.  Internet Security dialog should have been displayed.");
   }

   //
   // For proxy errors we need to ignore them, but not completely.  Since we didn't receive
   // the data for which we were looking, we need to reissue the request.
   //
   else
   {
    alert("There was a problem retrieving the Picasa page:\n" + req.statusText +
          " (" + req.status + ")");
   }
  }
 }
 return;
}

//
// Update Status Line
//
function updateStatus(newStatus)
{
 var myDocument = window.document;
 var myPs = myDocument.getElementsByTagName("P");
 var theP = null;

 for (var ii = 0; ii < myPs.length; ii++)
 {
  var pp = myPs[ii];

  if (pp.getAttribute("id") == "status")
  {
   theP = pp;
   break;
  }
 }
 if (theP != null)
 {
  var tn = myDocument.createTextNode(newStatus);

  theP.replaceChild(tn, theP.firstChild);
 }
}
</script>
</head>
<body onLoad="start()">
<p id="status">Starting...</p>
<h2>Matches Table</h2>
<table cellpadding="0" cellspacing="0" border="0" width="100%" id="matches">
<tbody>
</tbody>
</table>
</body>
</html>

Comment 10

[Rob Hudson]

With the proliferation of Tiddly Wiki applications and offline browser applications that use the local file system, Firefox must address this bug or be left behind when other products seamlessly handle this type of access.

Firefox is not just a web browser. It's a work environment. It's a way of life.

Comment 11

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

Nobody is arguing that this bug should not be fixed; that would make the bug WONTFIX, which it isn't.  We need patches and minimized test cases, not more people telling us they don't like the current behaviour. :)

Comment 12

[Jonathan Belanger]

(In reply to comment #11)
> Nobody is arguing that this bug should not be fixed; that would make the bug
> WONTFIX, which it isn't.  We need patches and minimized test cases, not more
> people telling us they don't like the current behaviour. :)
> 

Hi Mike,

Being a Software Engineering Manager for the past dozen years and Software Engineer for over 22 years, I fully understand the frustration when all you hear about is the behavior of a UI and the functionality of something.  Getting the functionality is very important, but unfortunately it's the behavior people notice.  I also understand the need to differentiate the behavior and functionality.  It is a software engineering perspective that I've seen and also one I have tried to focus on myself.  Unfortunately, separating the behavior from the functionality is problematic.  What the customer is going to experience is the behavior, as well as the functionality.  Therefore, they are equally important.  Being a programmer, I know that the problem reported here is more than likely an extremely simple one to fix (it is a persistence problem).

Jon.

Comment 13

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

(In reply to comment #12)
> Unfortunately, separating the
> behavior from the functionality is problematic. 

Nobody is suggesting that.  I'm saying "we don't need more people telling us that this is the wrong behaviour; we know it's the wrong behaviour, and will fix it".  There's no meaningful difference between "behaviour" and "functionality" at play, and more people lamenting the bug's existence won't help get it fixed faster.

The barrier to this bug being fixed isn't that people need convincing, it's
- more detailed analysis of when the bug was introduced
- more detailed analysis of what path in our code isn't working correctly (is the setting not being saved? is it not being read? creative people can probably figure out which of those is the case without even opening a debugger)
- a patch
- an automatable test for our suite

> Being a programmer, I know that the problem reported here
> is more than likely an extremely simple one to fix (it is a persistence
> problem).

You sound ideally suited to helping to narrow down the problem and produce a simple patch for it.  That would be a big help!

You'll probably want to get started with a debug build (see http://developer.mozilla.org/en/docs/Build_Documentation for instructions), and probably to hunt the regression range for this bug using
- Firefox alphas/betas (http://releases.mozilla.org/pub/mozilla.org/firefox/releases/)
- nightlies (http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/)
- hourly builds (http://hourly-archive.localgho.st/)

That you're a programmer is great, because it means I won't have to explain binary search, or why it means you'll probably only have to test a dozen builds. :)

(I thought we had a wiki page on finding regression ranges, but I can't locate it, alas.)

Comment 14

[Boris Zbarsky [:bzbarsky]]

This is a known bug in the new file policy.  :(   We should get it fixed in the next dot-release...

Comment 15

[Boris Zbarsky [:bzbarsky]]

I should add that disabling the new file policy helps with this, at the cost of reduced security.  Depending on your situation (e.g. what else this profile is used for), that might be an acceptable interim solution...

Comment 16

[Chris]

setting security.fileuri.strict_origin_policy to "false" in about:config prevents the dialog from opening

http://kb.mozillazine.org/Security.fileuri.strict_origin_policy

Comment 17

[Fraser Smith]

Didn't make any difference to mine.

Comment 18

[Jonathan Belanger]

The line of code that is causing the problem is:

netscape.security.PrivilegeManager.enablePrivilege("UniversalBrowserRead"); 

This is what causes the security dialog that does not get remembered between executions of firefox (also if I run a script in a tab and click allow, then open another tab and run the same or a different script, I have to click allow again.  So it also does not remember it from tab to tab in the same instance of firefox.).

Jon

Comment 19

[Jonathan Belanger]

This bug still exists in FF 3.1b3.  It is very annoying.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3) Gecko/20090305 Firefox/3.1b3

Comment 20

[didier ernotte]

Any update on this one? it is still there in FF 3.5b99

Comment 21

[Lance Haverkamp]

RE:
Platform:  	x86 Windows XP

Platform info is incomplete, I am seeing the same behavior in Linux (Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.2) Gecko/20090820 Firefox/3.5.2)

I suspect this is really Platform: All

Comment 22

[clement.cc]

I think I might have found what's going on.

I notice that the dialog is saying a script from "file://" is asking for the security capability. If you look at prefs.js manually or use the Firefox privileges wizard from Tiddlywiki at http://firefoxprivileges.tiddlyspot.com/, you'll see that every time you check the remember check box, it adds a per-file permissions rule as described in this document http://www.mozilla.org/projects/security/components/per-file.html. Except that they're using "file://" instead of the full file path.

The problem is that after bug 230606, this no longer grant the permission to all local files but that particular dialog apparently haven't been updated to write the rules using the new security model even if security.fileuri.strict_origin_policy is true. (the new default value)

Hence, every time Firefox reads back the remembered security decisions from prefs.js, all it gets is a bunch of non-working rules. It then asks for security permissions again. And if you keep checking the remember check box, your prefs.js is polluted with lots of equally non-working "file://" capability rules.

The fix is, obviously, to put the full file URI in the preference.

Temporary workaround: Use the Tiddlywiki wizard described above. Punch in your file's URI manually. That works for me.

Comment 23

[BugBot [:suhaib / :marco/ :calixte]]

In the process of migrating remaining bugs to the new severity system, the severity for this bug cannot be automatically determined. Please retriage this bug using the new severity system.

Comment 24

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:dveditz, could you have a look please?

For more information, please visit BugBot documentation.

Comment 25

[Daniel Veditz [:dveditz]]

enablePrivilege functionality was fully removed in bug 1448967. Long before that it was reserved for use in a testing environment and not enabled for the general web.