contentscript.js:77 Uncaught Error: uBlock Origin: aborting content scripts for http://limonte.github.io/svg/head.svg.xml

[limonte]

Describe the issue

When opening http://limonte.github.io/ I'm getting uncaught exception in console

contentscript.js:77 Uncaught Error: uBlock Origin: aborting content scripts for http://limonte.github.io/svg/head.svg.xml

One or more specific URLs where the issue occurs

http://limonte.github.io/

Screenshot in which the issue can be seen

Your settings

• Browser/version: Linux/Chrome 53
• uBlock Origin version: 1.9.8

  Your filter lists

Default filter lists

[gorhill]

Sort of by design -- the browser injects uBO's content script into a document which is not meant to be handled by uBO, and throwing is used as a mean to "return" from the script.

[limonte]

Thank you @gorhill for the quick response, what you're saying makes sense. Is there any workaround to get rid of that exception in console?

[gorhill]

I could wrap the whole code in the file into a single (function() { ... })() and return from this. However this just create yet another scope to carry around -- for no other purpose then that one specific case -- hence why I chose to throw here.

[limonte]

I could wrap the whole code in the file into a single (function() { ... })() and return from this.

That will be much better solution, as to me.

[lewisje]

Yeah, screw performance, I want no JS errors ever, not even the ones that users wouldn't see! 🙄

[gorhill]

Warning: below is off-topic:

@lewisje I saw your answer on ABP's board, I have to ask about:

In limited cases, it removes hidden elements from the DOM entirely (doing this in general is bad for performance).

I have no idea what you are referring to there. uBO does not remove hidden DOM elements. (I have considered a :remove operator in the past, but so far it's not justified yet.)

By the way, the original post had a different title and was much longer -- probably has been silently redacted by the moderators.

[lewisje]

I don't notice the original post in that thread, or my own reply, having been shortened.

Anyway, I didn't find much support for the notion that uBO removes elements from the DOM via cosmetic filtering in any case, but I did see this mention in the wiki: https://github.com/gorhill/uBlock/wiki/Inline-script-tag-filtering#why-is-the-new-inline-script-tag-filter-a-cosmetic-one

Whatever can't be blocked using a network request filter can be taken care by a cosmetic filter, which is the removal of DOM elements from a web page.

I have edited my post on the ABP forum to grey-out sections referring to the notion that ABP removes DOM elements.

[gorhill]

which is the removal of DOM elements from a web page

Yeah, bad wording -- I edited to the more accurate "hiding".

[gorhill]

I don't notice the original post in that thread, or my own reply, having been shortened.

I meant the original OP's post, not yours.

[giles-v]

I get the same issue reported in the OP. You can see it, for example, viewing this: https://upload.wikimedia.org/wikipedia/commons/a/a0/Svg_example1.svg

While I appreciate the users can't see these errors, they do spam out the console needlessly and make it harder to debug JS on sites which include SVGs. I get the same error repeated for every SVG on a page; on one site I'm working on, this means 8 or 9 "bogus" console errors on a page.

From a first-principles standpoint, if uBlock detects it's injected into an inapplicable context, why does it need to throw an Error? This isn't really an "application error" so much as the plugin correctly exiting when it's not needed. It seems like the kind of logging which would be valid in development, but not in an end-user context.

[gorhill]

It seems like the kind of logging which would be valid in development, but not in an end-user context.

This is not uBO outputting at the console, it is the browser reporting an uncaught (yet harmless in the current case) exception.

[giles-v]

I beg pardon, that's my language at fault. That should read, "It seems like throwing an Error here would make sense in development, but not in an end-user production context."

I do disagree that it's harmless. Unneeded exceptions decrease the signal-to-noise ratio and can make it harder to spot JS errors which actually need fixing in a web app. If a program's behavior encourages you to ignore exceptions, then we can probably agree that's a bad outcome.

I'm unclear why you prefer to keep this Error; I could see it being useful in dev to pass tests etc., but in a production system it adds no value. Is there a benefit to keeping it?

[gorhill]

Is there a benefit to keeping it?

I commented above:

• It's exceptional (rare), it occurs only when the browser tries to inject uBO's script in a non-HTML document.
• To fix this would require to create a function scope just for that one single exceptional (rare) case.

I do not expect this to change your opinion.

[giles-v]

OK, sure, I understand. I disagree that it's rare, since SVGs are becoming much more prevalent across the web.

I assume this will consequently be closed as WONTFIX but as you can probably gather, my vote would be for fixing this for the reasons I outlined.

[gorhill]

I keep it open because my mind is not 100% made whether I should fix this or not -- I am opened to all arguments.

[giles-v]

Well, if it helps to sway you, this feels more like a temporary hack than a long-term solution. Using an exception to control program flow is abusing the exception.

[tagdara]

This appears to be part of another fix for https://github.com/chrisaljoudi/uBlock/issues/456 and like Jestar342 I see this same problem, even when I've disabled uBlock for the specific site with the power button as described in https://github.com/chrisaljoudi/uBlock/issues/1641

My scenario is the development of an application which uses SVG's to show a weather forecast, meaning I get to see this error at minimum 7 times in the console and 40+ times if all of the options are expanded to show hourly forecasts.

And since all we're talking about here is these 3 lines of code:

if ( typeof vAPI !== 'object' ) { throw new Error('uBlock Origin: aborting content scripts for ' + window.location); }

It does seem overkill to have that many errors in the log just because uBlock can't be injected into an SVG, and even disabling it for the page doesn't help.

[gorhill]

This appears to be part of another fix for chrisaljoudi/uBlock#456

Nothing to do with that issue, throwing pointless nonsensical speculations here just adds noise. It has been explained why this choice was made.

Being forced to lock the thread.

[jakeNiemiec]

This happens for sites that use the facebook tracking pixel/scripts, even with uBlock disabled.

I suspect that uBlock is being targeted explicitly.

[gorhill]

What is a site that causes the above error message?

[jakeNiemiec]

On sites I develop for. This is what facebook provides (this is the brand new 2017 tracking pixel). As both a developer and a user, I want to be able to gracefully respect when a user has an ad-blocker.

To reproduce, simply visit https://www.facebook.com/tr with console open.

[gorhill]

Content scripts are not injected into images. I need a site making use of this to understand what is really happening.

[jakeNiemiec]

@gorhill Ok, here is a shot of the end result:

For full reproduction:

1. Go here
2. Press add to cart at the bottom.
3. Press checkout or goto this link
4. Open devtools and press Save & Continue, the error will happen onClick. (you should not have to put in any of that form info)

The error will happen even with uBlock Origin turned off...there is something weird going on with that POST request to that tracking pixel.

Edit: I should note that this is the vanilla behavior for the tracking script. (AFAIK)

[rolbr]

I am developing a SPA which makes heavy use of SVGs. Vivus is used to animate those SVGs. When loading the SVGs with Vivus (read: the SVGs are neither img src="" nor object nor inline SVG but loaded and injected into the DOM on the fly), my console is spammed with Uncaught Error: uBlock Origin: aborting content scripts for http://localhost:8080/static/navigation/nav-1.svg?0.17841232557985798 at contentscript.js:88

I learned in this thread that this error is harmless, still it decreases dev happiness since it makes finding real errors in the console somewhat hard. I have a lot of SVGs which produce a lot of those errors.

The only fix...

... for now is to filter all uBlock errors in the Chrome Console using /^((?!uBlock).)*$/ as per this answer on SO