when clicking on links with custom schemes the resulting request gets blocked

[msxfm]

Issue by bege10
Tuesday Feb 19, 2013 at 15:55 GMT
Originally opened as RequestPolicy/requestpolicy#362

---

Hi,
as soon as RequestPolicy blocking is enabled, the mailto links don't work any more. As soon as blocking is disabled they work again.

Windows XP SP3
Firefox 18.0.2
RequestPolicy 1.0.0b3

[msxfm]

Comment by herrsimon
Sunday Feb 24, 2013 at 23:03 GMT

---

Same behaviour here, using Firefox 19 on Linux and RequestPolicy 1.0.0b3.
RequestPolicy not only blocks mailto: links, but actually all external protocols (like nntp:// org-protocol:// etc.).

To add some more details: Clicking on an external link or calling it directly via javascript while RequestPolicy is active gives the gives the follotwing error:

Component returned failure code: 0x805e0006 [nsIDOMLocation.href]

I'm not familiar with the code but a quick look at it makes me guess that the _isInternalRequest() function in src/components/RequestPolicyService.js should check for some more cases in the first if statement.

@jsamuel Please have a look at this or point me in the right direction (might be able to fix it myself). As working org-protocol:// links are crucial for my workflow, I have to disable RequestPolicy a lot at the moment.

[msxfm]

Comment by packwidth
Thursday Jul 11, 2013 at 22:28 GMT

---

This has bitten me, too. Specifically magnet: and papers2: links. I noticed that there's a place in 1.0.0b3 to whitelist a scheme, but it insists on adding "//" to the scheme (eg, magnet://*) and still doesn't work (even if the scheme uses "//", like papers2: does.

[msxfm]

Comment by qkiel
Thursday Sep 19, 2013 at 06:24 GMT

---

There is annoying workaround for magnet links and works only until we close Firefox.
If we add new boolean string to about:config with value false:
network.protocol-handler.expose.magnet
then for this session only RequestPolicy won't block magnet links.

[msxfm]

Comment by packwidth
Thursday Sep 19, 2013 at 13:53 GMT

---

That works for me, and the same principle lets me fix mailto: and others. Unfortunately, the pref doesn't stick and adding it to user.js doesn't make it stick, either. I was able to make it stick by adding a lockPref for it (http://kb.mozillazine.org/Lock_Prefs), but I'm not sure if that will survive the next time Firefox upgrades.

[msxfm]

Comment by qkiel
Thursday Sep 19, 2013 at 19:00 GMT

---

What did you write into mozilla.cfg exactly?
Mine doesn't work:
//
lockPref("network.protocol-handler.expose.magnet", false)

I wonder if it's possible to enable rss button again.

[msxfm]

Comment by packwidth
Thursday Sep 19, 2013 at 19:15 GMT

---

That's what I used, except with a semicolon at the end. It apparently must be in the same directory as the Firefox executable.

To get it to read mozilla.cfg, you also need to edit "$firefox_executable_directory/defaults/pref/local-settings.js" and include:
pref("general.config.obscure_value", 0);
pref("general.config.filename", "mozilla.cfg");

I still have "user_pref("network.protocol-handler.expose.magnet", false);" in user.js (in my profile directory), but it should be completely overridden and so unnecessary.

[msxfm]

Comment by qkiel
Thursday Sep 19, 2013 at 20:56 GMT

---

Thanks for your help, sadly this doesn't work on Ubuntu 13.04
Under Linux proper places for mozilla.cfg and local-settings.js are not in normal profile directory, but:
/usr/lib/firefox/
/usr/lib/firefox/defaults/pref

Even though "network.protocol-handler.expose.magnet false" is changed to italic in about:config magnet links still don't work. I'll have to set this parameter by hand until RequestPolicy is fixed :/

[myrdd]

As @qkiel mentioned correctly (see #362 (comment)), clicking mailto: only fails if network.protocol-handler.expose.mailto is set to true. It seems that false is the default value in current versions of firefox, but this should be fixed nevertheless. I'm working on a fix.

[myrdd]

@bege10 @herrsimon @packwidth @qkiel
version 1.0.beta8 contains a workaround against this bug, so I close this issue. For details take a look at issue #447, it aims to solve this problem cleanly.