RequestPolicy UI doesn't handle Greasemonkey resources properly

[Watilin]

Related to #562, #447, #619 .

Browser and Add-ons

• Browser: Firefox 55.0.2
• RequestPolicy Continued 1.0.beta13.0
• Other add-ons:
  • Greasemonkey 3.11

RequestPolicy settings:

• Default policy: deny (allow same domain)

Steps to reproduce

1. Create and open a new Firefox profile
2. Install Greasemonkey and RequestPolicy Continued; restart
3. Save both files rpbug.user.js and rpbug.css (provided below) in one same folder
4. Navigate to where you saved the files and click the userscript to have Greasemonkey install it
5. Navigate to www.example.com

Observation

The CSS resource is blocked– this is normal. However, RP GUI displays a null blocked target.

When allowing requests from *.example.com to null then refreshing the page, another null blocked target appears, and this time one can only allow requests to null without a specified origin.

When allowing requests to null and refreshing the page a second time, yet another null blocked target appears, this time with no possible action.

Allowing either of those null targets has no effect on the blocking of the resource.

Expected behavior

The GUI should display the userscript resource as blocked target, and offer a way to unblock it.

Additional remarks

The request log shows an URI looking like greasemonkey-script:5a0f2edd-46fb-44fd-b7d6-92cd584f773e/css.

One can unblock the resource by manually adding a rule with greasemonkey-script as destination schema and leaving all other fields blank. Alternatively, allowing all targets from *.example.com also unblocks the resource.

---

The file rpbug.user.js

// ==UserScript==
// @name          rpbug
// @namespace     fr.kergoz-panic.watilin
// @description   provides a bug test case for RequestPolicy
// @include       http://www.example.com/
// @include       https://www.example.com/
// @resource      css   rpbug.css
// @grant         GM_getResourceURL
// ==/UserScript==

"use strict";

let $link = document.createElement("link");
$link.rel = "stylesheet";
$link.href = GM_getResourceURL("css");
(document.head || document.documentElement).appendChild($link);

The file rpbug.css

body {
  border: dashed 2px magenta;
}

[myrdd]

Thank you for your exemplary report! I can reproduce everything you describe (using Fx ESR 45.9.0). You mentioned several issues, all connected to the null problem (#619) in some way. However, wouldn't you expect RPC to allow any requests to greasemonkey-script:* by default? That's my main question to you. I'll explain the other issues nevertheless.

---

The CSS resource is blocked– this is normal.

As I've said above, maybe this shouldn't be normal for most users. I think an "extension compatibility" rule should be added. Is the UUID following moz-extension: different for each installation of the user script?

However, RP GUI displays a null blocked target.

[…]

Allowing either of those null targets has no effect on the blocking of the resource.

As you've said, this is tracked in issue #619.

When allowing requests from *.example.com to null then refreshing the page, another null blocked target appears, and this time one can only allow requests to null without a specified origin.

When allowing requests to null and refreshing the page a second time, yet another null blocked target appears, this time with no possible action.

I've seen this issue somewhere before, but since we're talking about the null destination here, I'd classify this issue as a duplicate of #619. When #619 is fixed, all null issues should be gone.

[myrdd]

Is the UUID following moz-extension: different for each installation of the user script?

Yes, it is. I've just tested it. So a compatibility rule should allow all requests to the greasemonkey-script scheme.

[Watilin]

However, wouldn't you expect RPC to allow any requests to greasemonkey-script:* by default? That's my main question to you.

To be honest, I didn’t thought about it that much. I guess I was used to this behavior.

But you’re right, userscripts can be considered as extensions and RP should not interfere with extensions. After all, if the user has trusted the installation of a userscript, they expect any part of it to be working.

[myrdd]

I created a gist which contains the two files:

https://gist.github.com/myrdd/63d9b593818436dffce0b0a14ee32e0c

Screenshot of the issue: