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

devtools: move topbar out of scrollable container #9077

Merged
merged 55 commits into from
May 30, 2019

Conversation

connorjclark
Copy link
Collaborator

@connorjclark connorjclark commented May 29, 2019

Split off from #9023. The scrollbar was over the topbar:

image

With these changes (+ #9023):

image

Restructures the report like this:

- lh-root
--- topbar
--- lh-container
------ sticky
------ scores header
------ lh-report

So that lh-container can be given overflow-y: scroll.

Open issue: the bottom of the report is cut off - so you can't see the LH version or the link to file an issue. Any ideas on that?

image

@brendankenny
Copy link
Member

Split off from #9023

what do you think about splitting all the way so we can land the progress in #9023 and then consider this rather than merging this into #9023?

@connorjclark
Copy link
Collaborator Author

Yeah, that's my intention. Just based it off #9023 so the diff is clear :)

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.

@hoten just a thought, does this mean we can start to unwind the scroll ancestor business from earlier and just do all our scroll logic on this one container?

If I'm understanding correctly, and that's a big if :), our report could always be height: 100% for example with our other container being the real scroll container, then feasibly we don't have to worry about how we are being embedded? Might make the seamless integrations like PSI more tricky to remember to support though

@@ -238,11 +223,25 @@ class ReportRenderer {
const stickyHeader = this._dom.createElement('div', 'lh-sticky-header');
stickyHeader.append(
...this._renderScoreGauges(report, categoryRenderer, specificCategoryRenderers));
reportFragment.appendChild(stickyHeader);
container.appendChild(stickyHeader);
Copy link
Collaborator

Choose a reason for hiding this comment

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

can we rename this var rootContainer or something while we're in here?

Copy link
Collaborator

Choose a reason for hiding this comment

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

WDYT of this change @hoten ?

Copy link
Collaborator

Choose a reason for hiding this comment

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

Oh, but I guess we have a separate lh-root, huh. Other name ideas but something that indicates its our root (potentially scroll) container for everything but top bar?

Copy link
Collaborator Author

@connorjclark connorjclark May 30, 2019

Choose a reason for hiding this comment

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

...reportContainer? I don't want to rename the CSS classes here tho.

Copy link
Collaborator

Choose a reason for hiding this comment

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

reportContainer WFM!

I'm not suggesting to rename any CSS classes, just the container var

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

done

reportFragment.appendChild(container);
container.appendChild(headerContainer);
Copy link
Collaborator

Choose a reason for hiding this comment

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

these two lines are the only other real significant changes? reportFragment -> rootContainer?

Copy link
Collaborator Author

@connorjclark connorjclark May 30, 2019

Choose a reason for hiding this comment

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

yes. most other stuff moved b/c of variable dependency. one thing moved because it made sense to do as setup for the function (the cat renderer stuff)

@@ -269,7 +269,7 @@
--header-padding: 16px 0 16px 0;
--plugin-icon-size: 75%;
--pwa-icon-margin: 0 7px 0 -3px;
--score-container-width: 92px;
--score-container-width: 97px;
Copy link
Collaborator

Choose a reason for hiding this comment

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

what's the effect here/why necessary?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

the text for the gauge titles was wrapping for Perf/A11y (in DevTools only) b/c the scroll bar steals some width.

@patrickhulce
Copy link
Collaborator

the bottom of the report is cut off - so you can't see the LH version or the link to file an issue. Any ideas on that?

Not sure why it's happening but can we add some padding to the bottom of the scroll container?

@connorjclark
Copy link
Collaborator Author

the bottom of the report is cut off - so you can't see the LH version or the link to file an issue. Any ideas on that?

Not sure why it's happening but can we add some padding to the bottom of the scroll container?

fixed by c10ea6e

@connorjclark
Copy link
Collaborator Author

@hoten just a thought, does this mean we can start to unwind the scroll ancestor business from earlier and just do all our scroll logic on this one container?

If I'm understanding correctly, and that's a big if :), our report could always be height: 100% for example with our other container being the real scroll container, then feasibly we don't have to worry about how we are being embedded? Might make the seamless integrations like PSI more tricky to remember to support though

I suppose... @exterkamp could talk more about PSI integration.

I've just noticed that the scroll bar is also over the topbar in the normal LH renderer (see now deployment). Just harder to notice since the scroll bar is only visible during use.

@brendankenny
Copy link
Member

I've just noticed that the scroll bar is also over the topbar in the normal LH renderer (see now deployment).

wait, is that bad? Now I'm questioning what the problem was and what the fix is doing :) It seems fine in the normally rendered report to me?

@connorjclark
Copy link
Collaborator Author

Shipping with a scroll container by default might make using the report renderer odd... but would need to test it out across PSI/the internal demo app first to see first-hand. Maybe we could merge as-is and consider changing it later?

@exterkamp
Copy link
Member

@hoten just a thought, does this mean we can start to unwind the scroll ancestor business from earlier and just do all our scroll logic on this one container?
If I'm understanding correctly, and that's a big if :), our report could always be height: 100% for example with our other container being the real scroll container, then feasibly we don't have to worry about how we are being embedded? Might make the seamless integrations like PSI more tricky to remember to support though

I suppose... @exterkamp could talk more about PSI integration.

Afaict this shouldn't be an issue for PSI. In PSI we just take the individual perf category from a PerformanceCategoryRenderer. Never mess with the header or topbar. So this shouldn't be a problem as this PR stands or if the report is made to height 100% b/c we never use a report so entirely there. 🤷‍♂️ I didn't test it thought before saying this, so 👀

@patrickhulce
Copy link
Collaborator

Maybe we could merge as-is and consider changing it later?

SGTM, twas just a thought afterall :)

@brendankenny
Copy link
Member

I'm not sure how to interpret that 👍 on my comment :)

If this is correct in the main report, what made the scroll bar different in devtools?

@connorjclark
Copy link
Collaborator Author

connorjclark commented May 30, 2019

aahhh my emoji meant to convey that I agree that it looks fine outside DT.

The bar being over is ok to me, in DevTools it was under and looked really weird. It's hard to see in the photos in the first post, but the scrollbar in the previous version went under the topbar, the fix does not because the topbar was moved out of the scrolling element.

@GoogleChrome GoogleChrome deleted a comment from googlebot May 30, 2019
@GoogleChrome GoogleChrome deleted a comment from googlebot May 30, 2019
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.

LGTM

Copy link
Member

@brendankenny brendankenny left a comment

Choose a reason for hiding this comment

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

this solution feels a lot like one that's going to be rolled back in the next release for the actual fix (an issue in the containing panel CSS?), but in the interest of shipping, let's get it in.

@GoogleChrome GoogleChrome deleted a comment from googlebot May 30, 2019
@connorjclark connorjclark merged commit 7671166 into master May 30, 2019
@paulirish paulirish deleted the rd-devtools-topbar branch June 10, 2019 17:27
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants