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

report: fix element screenshot position, lifecycle, styles #11846

Merged
merged 16 commits into from
Dec 17, 2020

Conversation

paulirish
Copy link
Member

@paulirish paulirish commented Dec 17, 2020

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 like margin-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 of lh-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).

  1. does overlay go on top of topbar? I think yes, cuz otherwise you can toggle the topbar menu and it displays under the overlay
  2. does overlay go on top of devtools toolbar? I wasn't sure but I checked the DevTools glasspane and it goes on top. Here's an example modal & glasspane in Network panel: rightclick table headers > response headers > manage header columns. (Also their glasspane is transparent, so I've done that too.) Anyway, this all convinced me that the overlay should sit on top of everything.

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:
image

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.

@paulirish paulirish requested a review from a team as a code owner December 17, 2020 02:42
@paulirish paulirish requested review from connorjclark and removed request for a team December 17, 2020 02:42
@google-cla google-cla bot added the cla: yes label Dec 17, 2020
Copy link
Collaborator

@patrickhulce patrickhulce left a 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;
Copy link
Collaborator

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? :)

Copy link
Member Author

@paulirish paulirish Dec 17, 2020

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.

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.

…er.js

Co-authored-by: Patrick Hulce <phulce@google.com>
Copy link

@Technotips786 Technotips786 left a 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.

Copy link
Collaborator

@connorjclark connorjclark left a 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
Copy link
Collaborator

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.

Comment on lines +157 to +158
// 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'));
Copy link
Collaborator

Choose a reason for hiding this comment

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

Suggested change
// 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?

Copy link
Collaborator

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 👍

Copy link
Member Author

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

@@ -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);
Copy link
Collaborator

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 => {
Copy link
Collaborator

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

@connorjclark
Copy link
Collaborator

image
is this expected (not being vertically centered)?

@connorjclark connorjclark changed the title report: element-screenshot lightbox fixes report: element screenshot overlay fixes Dec 17, 2020
@connorjclark connorjclark changed the title report: element screenshot overlay fixes report: fix element screenshot overlay positioning, lighten background Dec 17, 2020
Co-authored-by: Connor Clark <cjamcl@google.com>
Co-authored-by: Patrick Hulce <phulce@google.com>
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.

is this expected (not being vertically centered)?

it is vertically centered. 😄

(random image edits to prove the same amount of pixels on bottom as top:

image

.. vertically centered assuming the "overlay positioning aside" bit from the description"

Comment on lines +157 to +158
// 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'));
Copy link
Member Author

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

@paulirish paulirish changed the title report: fix element screenshot overlay positioning, lighten background report: fix element screenshot position, lifecycle, styles Dec 17, 2020
@paulirish paulirish merged commit 966a206 into master Dec 17, 2020
@paulirish paulirish deleted the fps-tweak-partytime branch December 17, 2020 21:12
@paulirish
Copy link
Member Author

@Technotips786 i'm looking for something halfway between the prodigy and orbital. any suggestions?

@connorjclark connorjclark mentioned this pull request Mar 10, 2021
16 tasks
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.

6 participants