-
Notifications
You must be signed in to change notification settings - Fork 9.4k
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: new inspector issues gatherer for Audit.IssueAdded events #10664
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll leave the review review to the folks you requested, but just wanted to throw that in there :)
@@ -151,6 +151,7 @@ const defaultConfig = { | |||
'seo/robots-txt', | |||
'seo/tap-targets', | |||
'accessibility', | |||
'issues', |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
how would you feel about something slightly more specific like audits-issues
or something more closely tying it to audits protocol?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
how would you feel about something slightly more specific like
audits-issues
or something more closely tying it to audits protocol?
+1 on something more specific if we can think of something good, and audits-issues
makes sense with the protocol names, but also seems like it could be a confusing name in lighthouse :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Having issues live in the Audits namespace in CDP makes coming up with a nice name tricky. I was thinking audits-issues as well but audits in this case doesn't make sense in a LH context. I was also thinking of maybe inspector-issues
as that's the top-level type for all issues.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I could get behind inspector-issues
👍
agreed audits-issues
is a bit weird
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
inspector-issues
SGTM too
(though is inspector
too ancient history for most folks these days? something like devtools-issues
is basically synonymous and may be more obvious what it's referring to)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was also thinking of maybe
inspector-issues
as that's the top-level type for all issues.
actually you already pointed out that's exactly what they're called in the protocol so ignore my earlier parenthetical :)
inspector-issues
SGTM
@@ -151,6 +151,7 @@ const defaultConfig = { | |||
'seo/robots-txt', | |||
'seo/tap-targets', | |||
'accessibility', | |||
'issues', |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
how would you feel about something slightly more specific like
audits-issues
or something more closely tying it to audits protocol?
+1 on something more specific if we can think of something good, and audits-issues
makes sense with the protocol names, but also seems like it could be a confusing name in lighthouse :)
types/artifacts.d.ts
Outdated
@@ -110,6 +110,8 @@ declare global { | |||
Fonts: Artifacts.Font[]; | |||
/** Information on poorly sized font usage and the text affected by it. */ | |||
FontSize: Artifacts.FontSize; | |||
/** The issues surfaced in the devtools Issues panel */ | |||
Issues: Artifacts.Issue[]; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ideally we can start with just what we need in a new artifact and then add to it as our needs grow. In this case I think we're only going to start with a mixed content audit so we don't need same site cookie issues?
Starting minimal keeps the artifacts smaller for when they need to be saved (e.g. a future issue we don't care about (yet) could add data URLs that are humongous, taking up disk space but never looked at) and we don't have to worry about code depending on them and changing our mind later (technically these won't be part of our public artifacts yet but it could happen :)
Rearranging a bit could help audits using Issues
, as well. To get the subset they want, any audit using an Issues
artifact of this form would have to do something like
const mixedContentIssues = artifacts.Issues
.filter(issue => issue.code === 'MixedContentIssue');
for (const issue of mixedContentIssues) {
// Check because `mixedContentIssueDetails` is optional
if (!issue.details.mixedContentIssueDetails) continue;
// use issue.details.mixedContentIssueDetails...
}
Instead, another form the artifacts could take would be something like
Issues: {
mixedContentIssues: Crdp.Audits.MixedContentIssueDetails[];
}
which moves the filtering to a single place in the gatherer (saving the audits from doing type juggling) and allows for easy extension of the type (just add another issue property) when there's another type of issue we want to write an audit for.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Beytoven this is the shape I was suggesting fyi
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@brendankenny Yeah, Connor and I had discussed this earlier and decided to let the team discuss it on this PR. I like the format that you and Connor have suggested for this use case. Just want to call out the trade off here is having to update the gatherer and type-definition (and by extension tests and mock data) any time a new or existing audit needs to consume an issue that isn't already used by another audit.
types/artifacts.d.ts
Outdated
@@ -471,7 +471,11 @@ declare global { | |||
devicePixelRatio: number; | |||
} | |||
|
|||
export interface Issue { | |||
export interface InspectorIssues { | |||
mixedContentIssues: Crdp.Audits.MixedContentIssueDetails[]; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nice!
}; | ||
}); | ||
/** @type {Array<LH.Crdp.Audits.MixedContentIssueDetails>} */ | ||
const mixedContentIssues = []; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ideas for making this cleaner, easily extensible later on:
- define the artifact obj first.
const artifacts = {
mixedContentIssues: [],
}
-
use a for/of loop on this._issues
-
naming–instead of
mixedContentIssues
, what aboutmixedContent
or evenMixedContent
? Code using will then read likefor (const issue of InspectIssues.MixedContent) { ...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just to make sure I'm clear, you mean use the for/of loop in place of the filter/forEach chaining that I have now? Then the inside would look something like w/ your suggestions:
if (issue.code === 'MixedContentIssue') {
artifact.MixedContent.push(issue.details.mixedContentIssueDetails);
}
Am I getting this right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes
}; | ||
|
||
for (const issue of this._issues) { | ||
if (issue.code === 'MixedContentIssue' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe drop the code check?
I wish the generated types were better here. It doesn't allow for type narrowing. https://github.com/ChromeDevTools/devtools-protocol/blob/master/types/protocol.d.ts#L2846
types/artifacts.d.ts
Outdated
@@ -472,6 +474,15 @@ declare global { | |||
devicePixelRatio: number; | |||
} | |||
|
|||
export interface InspectorIssues { | |||
MixedContent: Crdp.Audits.MixedContentIssueDetails[]; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wait, this should be mixedContent
lower case; capitalized first letter is (supposed to be) just for constructors.
Capitalized top-level artifact names was a confusing decision from a realllllly long time ago to get artifact names off of the gatherer constructor
that we're stuck with now but we shouldn't extend it to their properties :)
(I'm kind of surprised eslint doesn't flag it, maybe we turned it off because of tests or something)
class InspectorIssues extends Gatherer { | ||
constructor() { | ||
super(); | ||
/** @type {Array<LH.Crdp.Audits.InspectorIssue>} */ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i think you can remove InspectorIssue
from artifacts.d.ts btw
types/artifacts.d.ts
Outdated
mixedContent: Crdp.Audits.MixedContentIssueDetails[]; | ||
} | ||
|
||
export interface InspectorIssue { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i meant this can be removed
insecureURL: 'http://www.mixedcontentexamples.com/Content/Test/steveholt.jpg', | ||
mainResourceURL: 'https://www.mixedcontentexamples.com/Test/NonSecureImage', | ||
request: { | ||
url: 'http://www.mixedcontentexamples.com/Content/Test/steveholt.jpg', |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
steve holt!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm- can you update the devtools protocol package before merging? no need to add the new issue types, that can come on an as-needed basis
This PR adds an Issues gatherer that gets details from the Audit.IssueAdded protocol event. It's currently only used for Samesite cookie issues but will eventually include many other issue types such as mixed content and COEP.
Closes #10592