Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
limonte opened this issue Sep 25, 2016 · 24 comments

Comments

@limonte
Copy link

commented Sep 25, 2016

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

This comment has been minimized.

Copy link
Owner

commented Sep 25, 2016

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

This comment has been minimized.

Copy link
Author

commented Sep 25, 2016

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

This comment has been minimized.

Copy link
Owner

commented Sep 25, 2016

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

This comment has been minimized.

Copy link
Author

commented Sep 25, 2016

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

This comment has been minimized.

Copy link

commented Sep 26, 2016

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

@gorhill

This comment has been minimized.

Copy link
Owner

commented Sep 26, 2016

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

This comment has been minimized.

Copy link

commented Sep 26, 2016

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

This comment has been minimized.

Copy link
Owner

commented Sep 26, 2016

which is the removal of DOM elements from a web page

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

@gorhill

This comment has been minimized.

Copy link
Owner

commented Sep 26, 2016

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

This comment has been minimized.

Copy link

commented Sep 26, 2016

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

This comment has been minimized.

Copy link
Owner

commented Oct 6, 2016

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

This comment has been minimized.

Copy link

commented Oct 6, 2016

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

This comment has been minimized.

Copy link
Owner

commented Oct 6, 2016

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

This comment has been minimized.

Copy link

commented Oct 6, 2016

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

This comment has been minimized.

Copy link
Owner

commented Oct 6, 2016

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

This comment has been minimized.

Copy link

commented Oct 6, 2016

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 comment has been minimized.

Copy link

commented Oct 13, 2016

This appears to be part of another fix for uBlock-LLC/uBlock#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 uBlock-LLC/uBlock#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 comment has been minimized.

Copy link
Owner

commented Oct 13, 2016

This appears to be part of another fix for uBlock-LLC/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.

Repository owner locked and limited conversation to collaborators Oct 13, 2016

Repository owner unlocked this conversation Aug 15, 2017

@jakeNiemiec

This comment has been minimized.

Copy link

commented Aug 15, 2017

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

I suspect that uBlock is being targeted explicitly.

@gorhill

This comment has been minimized.

Copy link
Owner

commented Aug 15, 2017

What is a site that causes the above error message?

@jakeNiemiec

This comment has been minimized.

Copy link

commented Aug 15, 2017

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.

facebook_pixel_html_erb-heatwave-__rubymineprojects_heatwave-_rubymine_2017_2_2_eap

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

@gorhill

This comment has been minimized.

Copy link
Owner

commented Aug 15, 2017

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

@jakeNiemiec

This comment has been minimized.

Copy link

commented Aug 15, 2017

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

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)
    checkout___warmlyyours

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

This comment has been minimized.

Copy link

commented Aug 17, 2017

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

@gorhill gorhill closed this in fdcc951 Aug 17, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
7 participants
You can’t perform that action at this time.