-
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
report: css var for FPS, move overlay to container #12201
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.
Very nice solution! Looks good cross browser, as well.
}`; | ||
return styleEl; | ||
static installFullPageScreenshot(el, screenshot) { | ||
el.style.setProperty('--element-screenshot-url', `url(${screenshot.data})`); |
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 this go onto .lh-root
like the overlay is appended to? Then they could share the variable rather than having to call installFullPageScreenshot
twice (and have the 50k or whatever data url duplicated in the DOM)
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 to call
installFullPageScreenshot
twice
I guess once on first render and then again every time the overlay is opened, actually
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 thought there was a reason we couldn't do this, but I've forgotten since writing this yesterday. I'll take another look.
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.
cl/360815959 for context. in PSI we want to install the overaly above lh-root at the document root (position:fixed has some implications)
so yeah we would prefer the flexibility. (even tho i'd ideally like it scoped at the lh-root level)
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.
lh-root is tough because we don't know such an element at the time of rendering in render-report
. that's why we use report-container atm.
could move the "installation" to report-ui-features, but then that means the element thumbnails would not show at all unless report-ui-features is invoked.
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 make an issue for us to one day work out this gordian knot of a DOM we've created... #12254
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.
Hmm, I don't think this is as complicated as that, or at least lh-root
isn't the cause of the complexity. I was only suggesting it because that's where the overlay is currently inserted.
lh-root
is only programmatically used for the overlay currently, otherwise it's purely for CSS selectors. The one other programmatic use is for narrow devtools styling, and since .lh-narrow
is exclusively for devtools it should be querying for .lh-devtools
(not .lh-root
) anyways.
This isn't an emergency but it would be nice to simplify things while it's still paged into everyone's mind instead of kicking it down the road as a P3 and letting lh-root
continue to thread through things and create the very gordian knot you're 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 able to move the overlay element to the report container element, so now we don't have to add a new CSS var for each time we make that. that's a bunch better now.
I still don't have a good answer for the whole lh-root shenangins. PSI doesnt even have lh-container, so paul and I are gonna work around that by having these "install" functions accept an element on where to install things.
This will allow us to have multiple reports on a page, each with their own full page screenshot.
Tested in devtools too.