Skip to content

Loading…

console spam #1471

Open
skylize opened this Issue · 6 comments

3 participants

@skylize

Using this extension causes Chrome to spam the developer console with

GET https://some-really-long-url net::ERR_BLOCKED_BY_CLIENT.

It would be nice if you could capture and suppress these errors. Thanks.

@lewisje

I think that's what filtering console messages is for; anyway, I remember when gorhill tried to suppress those messages the best way he knew how, and that ended up conflicting with HTTPS Everywhere so he backed out that change: #18

@skylize

I disagree. Console filtering should not be considered a fix for anything, it's for workflow convenience. Thanks for pointing that out, as I can use this ugly bit of regex as temporary workaround:
^(?!.*?ERR_BLOCKED_BY_CLIENT)

But that regex has to be manually entered every single time DevTools is opened in a new window. The errors still show up in the error count at the top of DevTools with a bright red X symbol. The top line of the console must report that errors are filtered out. And I only get one regex field. If I want to filter anything else, I now have to merge it into this already complicated string, or expose these errors again.

The basic concept with error handling is you want errors to bubble up to avoid hiding something broken underneath. In this case the error is simply confirmation that uBlock did it's job. The only thing broken is uBlock failed to capture the error and respond by suppressing it.

@aug-riedinger

:+1:
Yes yes yes!
I agree with @skylize. I'm considering going back to ABP because of those errors: when I'm trying to debug my own errors, I don't want other error to interfere with mines.

@lewisje

IIRC ABP does the same thing uBlock does with blocked requests (cancelling rather than redirection), so you'll get the same flood of errors; meanwhile, AdBlock redirects a few requests last time I checked (images to a transparent 1x1px PNG, documents to about:blank), so if you want to minimize spam in the console, that's the extension you should choose.

@skylize

I was going to try to build up a proof of concept for this, but when I tried to make changes to the code, Chrome blocked the extension as corrupted.

Looking at this from Chrome, don't know how well it would carry to other browsers:

Blocking a request fires onErrorOccured event. I'm speculating here, but I would think you could register a listener to verify it was the expected error, then preventDefault() and/or stopPropagation() on the event.

@skylize skylize closed this
@skylize skylize reopened this
@aug-riedinger

I did try to switch (using Extensify) and I haven't had any ERR_BLOCKED_BY_CLIENT error since.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.