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

misc(treemap): elide origin from url if same as requestedUrl #12598

Merged
merged 2 commits into from
Jun 2, 2021

Conversation

connorjclark
Copy link
Collaborator

@connorjclark connorjclark commented Jun 2, 2021

The depth one script nodes have really long names because they are the entire URL of the network resource. We should elide if they share the same origin as the requested URL.

I did this in the Treemap UI instead of script-treemap-data because I thought it'd be nice to preserve the property that the names in the LHR are valid URLs.

Also added an (inline) tag to make the inline JS node apparent.

https://lighthouse-git-tm-url-elide-googlechrome.vercel.app/gh-pages/treemap/?debug

https://lighthouse-git-tm-url-elide-googlechrome.vercel.app/gh-pages/treemap/?gist=682f30fc539d16905557e8ce092adecf

ref #11254

@connorjclark connorjclark requested a review from a team as a code owner June 2, 2021 01:43
@connorjclark connorjclark requested review from patrickhulce and removed request for a team June 2, 2021 01:43
@google-cla google-cla bot added the cla: yes label Jun 2, 2021
@@ -468,7 +473,7 @@ class TreemapViewer {
const dataRow = cell.getRow().getData();
if (!dataRow.bundleNode) return '';

return `${dataRow.bundleNode.name} (bundle) ${dataRow.name}`;
return `${dataRow.bundleNode.name} ${dataRow.name}`;
Copy link
Collaborator Author

@connorjclark connorjclark Jun 2, 2021

Choose a reason for hiding this comment

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

this (bundle) tag was doubling up–already present in table datarow name.

for (const node of this.depthOneNodesByGroup.scripts) {
const url = new URL(node.name);
node.name = TreemapUtil.elideUrl(url, this.documentUrl);
if (url.href === this.documentUrl.href) {
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

This works as temporary solution, but misses the case of iframes's inline JS. Haven't ever tested something like that so no idea if the app even works :)

// to elide common parts of the URL so text fits better in the UI.
for (const node of this.depthOneNodesByGroup.scripts) {
const url = new URL(node.name);
node.name = TreemapUtil.elideUrl(url, this.documentUrl);
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I feel pretty good that these strings should be valid URLs, but should we do try/catches just in case?

Copy link
Collaborator

Choose a reason for hiding this comment

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

failure mode is that the whole treemap doesn't render, right?

let's do a try/catch :)

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 did this in the Treemap UI instead of script-treemap-data because I thought it'd be nice to preserve the property that the names in the LHR are valid URLs.

Good call, agreed 👍

I gotta say, as a third-party observer to a site, I'm not sure I was able to get much more out of each URL than before, but I suppose the site owner might be more familiar with all the paths.

// to elide common parts of the URL so text fits better in the UI.
for (const node of this.depthOneNodesByGroup.scripts) {
const url = new URL(node.name);
node.name = TreemapUtil.elideUrl(url, this.documentUrl);
Copy link
Collaborator

Choose a reason for hiding this comment

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

failure mode is that the whole treemap doesn't render, right?

let's do a try/catch :)

* @param {URL} url
* @param {URL} fromRelativeUrl
*/
static elideUrl(url, fromRelativeUrl) {
Copy link
Collaborator

Choose a reason for hiding this comment

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

elideOrigin?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

elideSameOrigin sounds nice

@@ -62,6 +62,15 @@ class TreemapUtil {
return string.slice(0, length - 1) + '…';
}

/**
* @param {URL} url
* @param {URL} fromRelativeUrl
Copy link
Collaborator

Choose a reason for hiding this comment

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

should this just pass in the origin directly instead? I feel like it's a little clearer what's happening and it's not the "elide the whole URL" behavior from before.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

passing URLs around is a nice pre-condition that the origin/url components are actually in the right format. altho if these were both strings the try/catch would be more contained..

Copy link
Collaborator

Choose a reason for hiding this comment

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

I agree for the url param should be a URL 👍 (unless you want for try/catch reasons)

My rationale for this second base parameter is that we're only using the origin component, and I think it'd make it clearer which was the base/match argument and which was being elided from the caller. Not a big deal though, can be solved via renaming elideSameOrigin SGTM

@@ -432,11 +442,6 @@ class TreemapViewer {
} else {
name = path.join('/');
}

// Elide the document URL.
if (name.startsWith(this.currentTreemapRoot.name)) {
Copy link
Collaborator

Choose a reason for hiding this comment

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

so this wasn't working?

Copy link
Collaborator Author

@connorjclark connorjclark Jun 2, 2021

Choose a reason for hiding this comment

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

no, it was, it just isn't needed now because the eliding happens elsewhere. this was just for the table rows.

Copy link
Collaborator

Choose a reason for hiding this comment

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

ah gotcha 👍

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.

3 participants