Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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(full-page-screenshot): resolve node rects during emulation #11536
core(full-page-screenshot): resolve node rects during emulation #11536
Changes from 40 commits
fa68fbf
d9f4d2e
97fbdae
a2391d2
1b6ba16
93960c5
90190c6
fe7b0f8
987c676
827a19f
437e3af
553eb21
551c53b
df7a9f2
c592163
f54e01d
315150c
77b72d9
5fb4dd6
69e71bb
8f6c886
3b62754
445b614
da33697
8566593
6f16838
7cee565
a18ead2
f043e2d
cf3359b
32b0dea
7783001
9ff001c
9cadb0b
4f82ee3
6cfe947
b4f129f
76835b1
0484a53
20ce34a
df63018
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
we should move
screenshot-config
off ofexperimental-config
and to a stable set of gatherers or folks messing with experimental gatherers/audits are going to have to deal with changes to these IDs unrelated to what they're up to. (e.g. there's no reason the "The following 2" comment will still apply to these two elements)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 are these sharing the same incremental map counter when they're in different execution contexts...
shouldn't it start over at
5-0-BODY
?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.
Because different gatherers, in the same pass and execution context, are collecting node details on the same elements.
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.
oh, and the reason you wouldn't see
5-0
or5-1
but see5-2
is perhaps because the first few nodes had zero size.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.
the sizes here are env-dependent so I just removed them.
This also illustrates that the same node can get assigned multiple ids (these rects are gonna be the same value, too). We could do a reverse lookup in getNodeDetailsImpl to dedupe this, but it'd only dedupe within the same pass. Should we?
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.
is there a reasonable range we could use? or are top/left at least consistent?
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 like the idea of deduping them, it would make the results less confusing. Would it be possible to add a pass number to the lhid?
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.
+1 to deduping, I wouldn't love a pass number for FR migration, but this is going to be tricky anyway
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.
alternative, if we provide more structure here we could do the de duping when collecting in full page screenshot. i'll experiment.
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 no sorry, that'd involve editing the ids in the LHR which we are trying hard not to do.
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.
iirc top/left were non constant, which was strange. We aren't losing anything by not having more rect checks here imo.
what I'd really like is a way to mark "no other keys" on an object.
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.
The context id ends up being a binary signal in the
lhId
s anyways (eitherpage
or a single execution context id, since if there had been other contexts in the pass they wouldn't still be around to query anyways :), so maybe consider a more generalizedwindow._isLighthouseIsolatedContext = boolean
.(Ideally we could get away without using it at all, but I can't think of a way to do that while keeping the original IDs in each artifact untouched)
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.
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.
FWIW, I also don't understand what
__lighthouseNodesDontTouchOrAllVarianceGoesAway
is trying to communicate :) It might be worth switching to something more straightforwardThere 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.
seems like we don't need this. the
for (const [id, node] of lhIdToElements.entries()) {
later on could just useelementToLhId
and reverse the order of the destructured array. 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.
ya but I'm assuming not performant. and this code is simpler/fewer lines.
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.
hmmm.. maybe you're thinking of something else?
what i'm proposing is definitely less work. and its fewer lines
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.
ya this is good. i did not think to do just a
Map<HTMLElement, string>
, was stuck on thinking of it asMap<string, HTMLElement>
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.
Can we just put
getNodeDetails.toString()
in the exports and remove this?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.
yeah i considered that as well, though this fn is a little different from the rest in that it depends on all the others. so we need those stringified functions inlined here within this one.
when i worked on this with @adrianaixba it seems the most practical to just define this fn as a string and skip the conversion in order to make sure all the deps were available. (otherwise i figured whereever we used getNodeDetails in gatherers, we'd also need to inject each of its dependency fns as well.
i still feel pretty decent this was the right compromise for DX, but if there's another good solution we can def explore it.
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 had to add non trivial code to this function so I split it out, but am keeping the stringified dep export.