FF 19, Private Browsing: Can't install userscript from page with HTTP Auth #1717

Open
JonnyJD opened this Issue Feb 27, 2013 · 6 comments

2 participants

@JonnyJD

Starting with FF 19, Greasemonkey will not open the install window when on a page with a userscript, if that page is protected with HTTP Auth (Digest and Basic both don't work).
(FF 18 works fine, the Problem was reproduced on Linux and Windows)

I created a test page and script for this report:
http://kraehen.org/test/test.user.js (with HTTP Digest Auth)
User: test
Password: test
The same script will be installed without the AUTH:
http://kraehen.org/tmp/test.user.js (without AUTH)

The Problem is the same with Greasemonkey 1.7.1 and Greasemonkey 1.8beta3 (this is the version I use for the report)

The error message in the log is:

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

The code at line 257:

    this._tempDir.remove(true);

Which is weird, the surrounding code 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);
  }

I copied function getTempDir() from resource://greasemonkey/util/getTempDir.js. This is not in the same file.

This might be a problem in FF, but I wanted to report it here first, to check.
Additionally this might be some security thing in the new FF that might need a change in Greasemonkey.

Should I submit this to Mozilla? Is the information I gathered correct/usable for Mozilla?
Did I miss anything of importance?

EDIT: I added @grant none to the test script. No difference.

@JonnyJD

I should note that this is an install-time-only problem. After I installed the script in a different way. I have no problem accessing Digest Auth pages with XHR (GM or not, with CORS).

@arantius
Collaborator

Works for me with latest beta channel Firefox as of now (20), on Linux and Mac, except the first time (if I have to type the credentials in). Definitely get no errors logged, and no failures.

@JonnyJD

Installing FF 20 (beta) didn't help. However, I found out why:

I (and probably also the user got the report for my script from) used the "Private Browsing" mode in the tests.
(Tools -> Privacy -> History -> "Never remember history")
Deactivating the mode (needs FF restart) I have the behavior you got.

Well, I would understand if both, with and without Auth would fail to install in "Private Browsing" mode.
However, only the HTTP Auth page fails to install and that is kind of weird.

Now I have a workaround for my users, though.

@JonnyJD

I went ahead and created a ticket upstream: https://bugzilla.mozilla.org/show_bug.cgi?id=847192

@arantius
Collaborator

So here's what I'm seeing now:

"Normal" history settings, the first click on a script fails, which causes navigation to the script, which gives the auth prompt. A second visit/reload will work.
Private browsing window: even after the first failure/login, further loads do not send the Authorization header, so you get stuck in a loop.
Open "normal" window to the appropriate place, auth successfully. Then open a PBW and navigate to the script: it sends the Authorization header and installs like expected.

This is such an edge case (must be using private browsing AND http auth), and seems so hard to fix, that I'm going to drop the priority of this way down.

@JonnyJD

Hm, this is a somewhat rare use case. Most userscripts are hosted on the open, without any authorisation.
Enabling private browsing isn't that rare. Well, I don't care much about calling it "private browsing", but disabling history is common, which seems to enable that mode.

The actual script itself is a helper script for an online game for our alliance. So we obviously can't open that up, since these are "internals".

I still think this is a problem on the end of FF in the definition what private browsing actually is and what it should do.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment