-
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: fix element screenshot position, lifecycle, styles #11846
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 like this approach 👍
@connorjclark how do you feel about this alternative?
if (reportEl.classList.contains(screenshotOverlayClass)) return; | ||
reportEl.classList.add(screenshotOverlayClass); | ||
const topbarEl = dom.find('.lh-topbar', dom.document()); | ||
const containerEl = topbarEl.parentElement; |
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.
want to add the explanation you had over VC for why it conceptually belongs next to the topbar? :)
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.
since your comment I changed this.
and at the top i added this explanation
DOM-wise the position of the overlay doesn't matter since it rolls up to its containing block. It can remain a child of .lh-report so there's no diff, but I slightly prefer it's a child of lh-root so it has more visibility.
|
||
dom.document().addEventListener('click', e => { | ||
containerEl.addEventListener('click', e => { |
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
const overlay = dom.createElement('div'); | ||
overlay.classList.add('lh-element-screenshot__overlay'); | ||
const overlay = dom.createElement('div', 'lh-element-screenshot__overlay'); | ||
containerEl.insertBefore(overlay, topbarEl.nextElementSibling); |
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
lighthouse-core/report/html/renderer/element-screenshot-renderer.js
Outdated
Show resolved
Hide resolved
…er.js Co-authored-by: Patrick Hulce <phulce@google.com>
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 can not understand 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.
QAing now. flushing comments.
}; | ||
const rootEl = dom.find('.lh-root', dom.document()); | ||
if (!rootEl) { | ||
return console.warn('No lh-root. Overlay install failed.'); // eslint-disable-line no-console |
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.
nit: these return <void>
calls give me the heebee-jeebies. reminds me of the days of express apps and callback hell. consider return
on a separate line?
it is also a pattern that I don't think we do anywhere else.
lighthouse-core/report/html/renderer/element-screenshot-renderer.js
Outdated
Show resolved
Hide resolved
// Only activate the overlay for clicks on the screenshot *preview* of an element, not the full-size too. | ||
const el = /** @type {?HTMLElement} */ (target.closest('.lh-node > .lh-element-screenshot')); |
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.
// Only activate the overlay for clicks on the screenshot *preview* of an element, not the full-size too. | |
const el = /** @type {?HTMLElement} */ (target.closest('.lh-node > .lh-element-screenshot')); | |
const thumbnailEl = /** @type {?HTMLElement} */ (target.closest('.lh-node > .lh-element-screenshot')); |
maybe says same thing but without a comment?
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'm to blame for the comment :) WFM 👍
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.
one way this'll clean up is if we use .lh-element-screenshot--thumbnail
and .lh-element-screenshot--lightbox
everywhere. i can do this in a followup
lighthouse-core/report/html/renderer/element-screenshot-renderer.js
Outdated
Show resolved
Hide resolved
@@ -104,6 +104,7 @@ | |||
--image-preview-size: 48px; | |||
--metric-toggle-lines-fill: #7F7F7F; | |||
--metrics-toggle-background-color: var(--color-gray-200); | |||
--modal-overlay-background: rgba(0, 0, 0, 0.3); |
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.
--screenshot-overlay-background
? or are you anticipating future modals?
|
||
dom.document().addEventListener('click', e => { | ||
// Add a single listener to the top container to handle all clicks within (event delegation) | ||
rootEl.addEventListener('click', e => { |
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.
(not now, but for later)
should we listen to resize so we can re-make an open overlay? things get messy when you dock/undock, but also impacts just resizing the window of a standalone report
Co-authored-by: Connor Clark <cjamcl@google.com> Co-authored-by: Patrick Hulce <phulce@google.com>
lighthouse-core/report/html/renderer/element-screenshot-renderer.js
Outdated
Show resolved
Hide resolved
lighthouse-core/report/html/renderer/element-screenshot-renderer.js
Outdated
Show resolved
Hide resolved
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.
// Only activate the overlay for clicks on the screenshot *preview* of an element, not the full-size too. | ||
const el = /** @type {?HTMLElement} */ (target.closest('.lh-node > .lh-element-screenshot')); |
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.
one way this'll clean up is if we use .lh-element-screenshot--thumbnail
and .lh-element-screenshot--lightbox
everywhere. i can do this in a followup
@Technotips786 i'm looking for something halfway between the prodigy and orbital. any suggestions? |
this is an alternative to #11843 and #11844
(and here's the diff against #11843, which may be useful: fps-tweak-viewport...fps-tweak-partytime )
okay a few things..
use fixed positioning to keep the overlay on top of the report content
if our overlay element was placed higher up in the devtools DOM,
pos:abs
would work. (That's what it used there for their equivalent "glassPane" component).i don't see a good way to use
pos:sticky
without a nasty hack likemargin-bottom: -100vh;
to fix it pushing down the report content.fixed
works well. DOM-wise the position of the overlay doesn't matter since it rolls up to its containing block. It can remain a child of.lh-report
so there's no diff, but I slightly prefer it's a child oflh-root
so it has more visibility.overlay positioning aside
There are options but it gets interesting when considering our report within another page/webapp. (eg DevTools).
size the lightbox screenshot relative to the overlay
with the overlay the size we want, we can use its dimensions as input for the
maxLightboxSize
which goes into the amazing sizing algorithm. that thing is too sweet and handles landscape/portrait viewports so so well.this means we add the overlay to the dom first and then measure it, but i think that's OK!
small style tweaks on lightbox overlay.
it had 20px margin that it wanted for the thumbnail but was being applied in the lightbox too:
also i added a 1px
outline
around it, just for visual contrast. (yay for outline not affecting dimensions)and I lessened the overlay's gray bgcolor a tad. more opacity ~= less dark. and in devtools, it's transparent to match the glasspane.
(obv these are not critical and i can defer till later if desired)
fix lightbox click lifecycle
basically the same thing that #11845 was getting at. The core problem is that we use the
.lh-element-screenshot
class for both thumbnails and lightbox images.I kept @connorjclark's "moved the listener to the rootEl, instead of the document". 👍
And after starting with adding an extra
if elem.closest(am-i-in-the-lightbox) return;
I realized the existing selector could be tweaked.