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

core(errors-in-console): ignore BLOCKED_BY_CLIENT.Inspector errors #11901

Merged
merged 4 commits into from
Jan 12, 2021

Conversation

paulirish
Copy link
Member

the .Inspector Network.BlockedReason indicates it's devtools instrumentation itself that's blocking. And we see cases where this crops up and is just noise.

fixes #10198

@paulirish paulirish requested a review from a team as a code owner December 29, 2020 23:13
@paulirish paulirish requested review from connorjclark and removed request for a team December 29, 2020 23:13
@google-cla google-cla bot added the cla: yes label Dec 29, 2020
Co-authored-by: Connor Clark <cjamcl@google.com>
'level': 'error',
'timestamp': 1506535813608.003,
'url': 'https://www.facebook.com/tr/',
'text': 'Failed to load resource: net::ERR_BLOCKED_BY_CLIENT.Inspector',
Copy link
Collaborator

@connorjclark connorjclark Dec 29, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IMO this test case is unnecessary, given the next few tests are exercising the filter feature. At minimum, i'd like to see it moved to after the filter tests (As it builds on them)

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would like to see the test remain as it describes a new, important part of this audit's default state of being. No real preference for position on my end :)

Copy link
Collaborator

@connorjclark connorjclark Jan 5, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it's not new, it's a parametrization of what multiple previous test cases has already proved to work (that the ignoredPatterns options works as intended). it might as well be assert.equal(ErrorLogsAudit.defaultOptions().ignoredPatterns, ['whatever']); (my preferred change, actually). Just an idea- I like the process of tests building on top of each other, sort of like a mathematical proof.

At the least, please move the test to after the ones that assert filtering works.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it might as well be assert.equal(ErrorLogsAudit.defaultOptions().ignoredPatterns, ['whatever']); (my preferred change, actually)

Sorry, I didn't realize that's what you were suggesting. It sounded to me like you wanted the assertion of this being the default removed, which I didn't :)

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It wasn't originally, your feedback evolved my stance :)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure why we're going to town on this fairly innocuous test, but I'll join in too :)

The test seems good as is to me. We don't care about how exactly the default pattern comes in, just that ERR_BLOCKED_BY_CLIENT errors are filtered out, so that's what should be tested.

If e.g. we decide we want to merge ERR_BLOCKED_BY_CLIENT.Inspector into whatever options are passed in instead of having the passed-in options overwrite the default (the normal auditOptions behavior) -- so ERR_BLOCKED_BY_CLIENT.Inspector couldn't go into defaultOptions -- there's no reason for this test to have to be rewritten.

Agreed that it makes sense to move into the 'options' test block, and (supernit) maybe it('filters out blocked_by_client.inspector messages by default', ...?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

test left impl left as is. moved it to a new defaultOptions group right after options:

image

@@ -45,10 +45,9 @@ class ErrorLogs extends Audit {

/** @return {AuditOptions} */
static defaultOptions() {
return {};
return {ignoredPatterns: ['ERR_BLOCKED_BY_CLIENT.Inspector']};
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My initial reaction was .Inspector might be too narrow since I didn't remember it always having that suffix, but I couldn't find reports of it without it, so I might be making that up. Calling it out in case you had the same initial thought and were on the fence for another nudge :)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There's a bunch of other blockedReasons that are fairly legit, so i think preserving those results seems good. https://chromedevtools.github.io/devtools-protocol/tot/Network/#type-BlockedReason

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ya for sure, but those would be caught by {ignoredPatterns: ['ERR_BLOCKED_BY_CLIENT']}? I was questioning if the .Inspector part needs to be here.

Copy link
Member Author

@paulirish paulirish left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

PSI: "Browser errors were logged to console" due to Inspector-blocked resource
5 participants