Feature Request: allow uBlock to run on chrome:// urls

[fysics]

Updated issue title. Previous title was "uBlock no longer respects #extensions-on-chrome-urls flag"

A previous version worked on chrome urls with the appropriate flag set. uBlock no longer does this, as of appx a few weeks ago.

The extension provides value on chrome urls despite there being no ads and the potential security concerns of enabling the appropriate flag. I use it to hide recent sites on the new tab page with a simple cosmetic filter.

[gorhill]

Ok, sorry, I have no idea what this is about. What is #extensions-on-chrome-urls? Ok, you mean pages with URLs like chrome://...?

[fysics]

It's a flag that can be passed to chrome.exe upon launching (or alternatively turned on using the chrome://flags page) that allows extensions to run on chrome:// urls (for example, the new tab page, the settings page, etc.)

It is normally disabled for security reasons.

[fysics]

From the chrome://flags page: "Enables running extensions on chrome:// URLs, where extensions explicitly request this permission."

Here is a link (copy and paste it) that will take you directly to the flag if you are running chrome: chrome://flags/#extensions-on-chrome-urls

[gorhill]

The extension has always constrained itself to work only on https?:// URLs since the beginning. It's enforced in the manifest file, the onBeforeRequest() handler, etc. You are saying it used to work on chrome:// pages?

[fysics]

I do remember it working, yes, as I created a rule to hide recent sites on the new tab page with a cosmetic filter. I've also been running various development or nightly builds of chrome(ium), so it's possible one of those builds was not respecting permission declarations (? proper word?) which caused it to allow your extension to run when it would not have normallybeen allowed to (because uBlock was not explicitly requesting permission to run on those urls).

Regardless, it was nifty while it lasted and I did not experience unexpected negative effects.

If your extension does request permission to run on chrome:// urls, it would only be respected if the user passes that flag to chrome, which subsequently causes a warning to be shown. The net effect for most users would be inconsequential.

[ghost]

uBlock working also on the chrome:// pages would be great, I would like to hide new tab page items with uBlock.

[gorhill]

I would need to try that flag and see if the content scripts are injected - since this is these which handle cosmetic filtering, and you are telling me what worked were the cosmetic filters. That would be weird if that works because it's the declarations in the manifest which prevent these content scripts from being injected if not https, so it is really enforced by the browser, not the extension code.

My experience with allowing the extension on chrome:// page is that this can lead to many unwanted and difficult to diagnose side effects. I remember with HTTPSB the Hangout extension breaking because of this. Not sure I want to deal with that kind of issue at this point as I am trying to stabilize what is already there.

[ghost]

Great, no need to focus on this issue in my case.

[fysics]

Agreed. Perhaps leave it open for some future time?

[gorhill]

Sure.

[leaumar]

I assume this would also count for Firefox chrome:// pages? In my case, the problem is that netvideohunter (video sniffer/downloader) has ads in its management page that I'd like to get rid of, but ublock refuses to work on it. http://puu.sh/eKfSl/190b0a220d.png

[ghost]

If I could do this, presumably I could block the Speed Dial 2 Pro Ad
when using that extension.

On 1/19/15, TheRealFaziri notifications@github.com wrote:

I assume this would also count for Firefox chrome:// pages? In my case, the
problem is that netvideohunter (video sniffer/downloader) has ads in its
management page that I'd like to get rid of, but ublock refuses to work on
it. http://puu.sh/eKf7f/1c592cdd85.png

---

Reply to this email directly or view it on GitHub:
gorhill/uBlock#105 (comment)