847192 - greasemonkey fails with NS_ERROR_FAILURE on nsIFile.remove with Private Browing on HTTP Auth protected page

Status: RESOLVED WONTFIX

(Firefox :: Extension Compatibility, defect)

Description

[Johannes Dewender]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:18.0) Gecko/20100101 Firefox/18.0
Build ID: 20130206201250

Steps to reproduce:

Install Greasemonkey (1.7.1 or 1.8 (development), no difference)
https://addons.mozilla.org/en-US/firefox/addon/greasemonkey/
This doesn't seem to be GM-only or a GM bug, but the bug surfaces with it.
See also: https://github.com/greasemonkey/greasemonkey/issues/1717

Change to "Private Browsing" with
Tools -> Privacy -> History -> "Never remember history"
(needs FF restart normally)

Go to 
http://kraehen.org/test/test.user.js (protected with HTTP Digest Auth)
user: test
password: test


Actual results:

After you logged in, the script's code appears in the browser window. (doesn't change on reload)

In the error log:

Fehler: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIFile.remove]"  nsresult: "0x80004005 (NS_ERROR_FAILURE)"  location: "JS frame :: resource://greasemonkey/remoteScript.js :: <TOP_LEVEL> :: line 257"  data: no]
Quelldatei: resource://greasemonkey/remoteScript.js
Zeile: 257

Code at line 257:

 this._tempDir.remove(true);

Surrounding Code (to tell what _tempDir actually is):

function getTempDir(aRoot) {
  var file = (aRoot || TMP_DIR).clone();
  file.append("gm-temp");
  file.createUnique(DIRECTORY_TYPE, GM_constants.directoryMask);
  return file;
}
...
this._tempDir = GM_util.getTempDir();
...
 if (this._tempDir && this._tempDir.exists()) {
    this._tempDir.remove(true);
  }


No Greasemonkey reaction.


Expected results:

Greasemonkey should have opened a window and ask for installation of the script.
The same script can be installed without Http Auth from:
http://kraehen.org/tmp/test.user.js

Which shows the expected behavior. (Also there is no error message)

Comment 1

[Johannes Dewender]

I forgot some code that might be interesting:

const GM_constants = {
  'directoryMask': parseInt('750', 8),
  'fileMask': parseInt('640', 8),
};

const DIRECTORY_TYPE = Components.interfaces.nsIFile.DIRECTORY_TYPE;
const TMP_DIR = Components.classes["@mozilla.org/file/directory_service;1"]
    .getService(Components.interfaces.nsIProperties)
    .get("TmpD", Components.interfaces.nsIFile);



The bug was first found with FF 19 and reproduced by a user of mine and myself on Windows and Linux.

Installing FF 20 didn't make a difference for this issue so I set FF 20.

I am trying to install Aurora and later possibly the Nightly to try it there.
It takes a long time downloading Aurora though, for some reason.

Comment 2

[Johannes Dewender]

It does work on FF 18 (that is the browser I am submitting the report from).
You have to reload the page after logging in though.

Comment 3

[Johannes Dewender]

Now tested on Aurora and Nightly. No changes (issue is still present)

Comment 4

[Anthony Lieuallen]

This is probably Greasemonkey's issue, but I haven't had time to check carefully yet.

Comment 5

[Loic]

(In reply to Johannes Dewender from comment #1) 
> The bug was first found with FF 19 and reproduced by a user of mine and
> myself on Windows and Linux.
> 
> Installing FF 20 didn't make a difference for this issue so I set FF 20.

I tried your STR with a nuild from May 2012 and the issue is already present. So, probably a bug in GM.

Comment 6

[Anthony Lieuallen]

This is definitely a Greasemonkey issue, not Firefox.

Comment 7

[Anthony Lieuallen]

Though I wonder what the behavior is supposed to be, when it comes to http auth and private browsing?

https://github.com/greasemonkey/greasemonkey/issues/1717#issuecomment-17010041

My experience seems to be that it leaks out of normal windows into private windows.  And doesn't persist (quite) within private windows.  I can provide lots more detail if any of this sounds surprising.

Comment 8

[Johannes Dewender]

I am not sure what the exact definition of private browsing is on the FF end,
but when I disable saving of browser history (something that is stored locally) that doesn't necessarily mean I want to disable HTTP Auth.
As far as I understood the point is to make it private on the local end. Since websites can still track you anyways.

I do understand there are potential problem with that, since FF still can't log out of HTTP Auth sessions. So technically you can prove somebody was at a page just because he is still "logged in".

Comment 9

[Jorge Villalobos [:jorgev] (he/him)]

Mass-closing old Extension Compatibility bugs that relate to legacy add-ons or NPAPI plug-ins. If you think this bug is still valid, please reopen or comment.

Sorry for the bug spam, and happy Friday!