Skip to content

report: source-location for linkifying#9354

Merged
connorjclark merged 64 commits into
masterfrom
ui-location-details
Nov 20, 2019
Merged

report: source-location for linkifying#9354
connorjclark merged 64 commits into
masterfrom
ui-location-details

Conversation

@connorjclark

@connorjclark connorjclark commented Jul 11, 2019

Copy link
Copy Markdown
Collaborator

Linkify source code in DevTools.

Fixes: #6436, second half of #5443,

I've done font-size here. I haven't explored what other audits this could be done for. font-size only applies to CSS, but the changes here should be sufficient for JS/HTML too.

I've also made the line/columns that font-size reports more accurate. Namely:

  1. For inline styles, the stylesheet's startColumn was always being add to the rule's column. However, this is only valid if the stylesheet and the rule begin on the same line in the HTML.
  2. For inline styles with a sourceURL magic comment, the line/column was relative to the HTML file. I've changed it to be relative to the beginning of the style tag, as if it were its own file. This may be worse for UX (harder to pinpoint where to look in the HTML?). Open to tweaking this - note that, the data {url: <source mapped url>, line: <line relative to script tag>, column: <ditto>} is necessary for DevTools to link to this file in the Source panel, so without this change that gets complicated.

LH report (outside DevTools) before/after ...

Before:

image

After:

http://misc-hoten.surge.sh/lh-reports/pr-9354.html
image

GIF of it working in DevTools:

lh-dt-ui-location-linkify

Associated Chromium changes: https://chromium-review.googlesource.com/c/chromium/src/+/1694144

Test it out:

node lighthouse-cli/ http://misc-hoten.surge.sh/lh-ui-location-font-size/ --only-audits=font-size --view

@patrickhulce patrickhulce left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

this is awesome!! a few concerns with the new attribution method, but I think this approach puts us in a much better place to be able to handle those challenges 👍

Comment thread lighthouse-core/report/html/renderer/details-renderer.js Outdated
Comment thread lighthouse-core/audits/seo/font-size.js Outdated
Comment thread lighthouse-core/report/html/renderer/details-renderer.js Outdated
Comment thread types/audit-details.d.ts Outdated
Comment thread lighthouse-core/audits/seo/font-size.js
Comment thread lighthouse-core/audits/seo/font-size.js
@vercel vercel Bot temporarily deployed to staging July 11, 2019 21:55 Inactive
@brendankenny

Copy link
Copy Markdown
Contributor

I've also made the line/columns that font-size reports more accurate.

can we deal with these separately? They seem related but with significantly different concerns (audit internals vs report rendering/devtools integration)

@connorjclark

Copy link
Copy Markdown
Collaborator Author

can we deal with these separately? They seem related but with significantly different concerns (audit internals vs report rendering/devtools integration)

Done! #9356

@vercel vercel Bot temporarily deployed to staging July 12, 2019 05:27 Inactive
Comment thread lighthouse-core/audits/seo/font-size.js

@paulirish paulirish left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

works for me!

Comment thread lighthouse-core/audits/seo/font-size.js
element.classList.add('lh-source-location');
element.setAttribute('data-url', item.url);
// Should pass `line` to `data-line` as zero-indexed, as DevTools expects that for linkifying.
element.setAttribute('data-line', String(item.line));

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

i think .toString() is a little favored over using the constructor.

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

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

fyi this file uses String() a few times but never toString

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

fyi this file uses String() a few times but never toString

yeah, I don't know how that happened in here but generally good to stick with the ambient style

@connorjclark connorjclark Aug 31, 2019

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

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

changed to toString()

note, if a plugin happens to provide a bad value (or no value) here, it would now error the renderer.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Sorry, I was agreeing with you that String() is fine in here since it's the established style

(there's only so much we can do against a plugin that refuses to use our types, though. you don't even need a plugin, you could just save a bad lhr to a gist and load it in the viewer)

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

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

oops, reverted.

Comment thread types/audit-details.d.ts
Comment thread types/audit-details.d.ts Outdated
Comment thread lighthouse-core/report/html/renderer/details-renderer.js
* @protected
*/
renderSourceLocation(item) {
if (!item.url) {

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

this shouldn't be possible now with the changes to make url required, right?

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

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

I'm guarding against an empty string here. Perhaps that's not necessary, and just allowing the url to be meaningless is better than showing nothing.

It may be possible to get an empty string from stylesheet.sourceURL if it came from a comment - I'd have to check. It is certainly possible for a plugin to provide an empty string.

Comment thread lighthouse-core/report/html/renderer/details-renderer.js Outdated
}

element.classList.add('lh-source-location');
element.setAttribute('data-url', item.url);

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

already done in renderTextURL?

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

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

is it?

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

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

oh, didn't see dataset.url =

There is a difference - renderTextURL only sets the url if it is a valid URL. However, we can expect a sourceURL to not be a valid URL, yet it is still needed to resolve correctly with the devtools front end (it know about styles.css if there was a magic comment defining it, even if it isn't a full url).

maybe this should be data-source-url and data-source-line? would also prevent clash with the 3p filter.

Comment thread lighthouse-core/audits/deprecations.js Outdated
Comment thread lighthouse-core/audits/deprecations.js Outdated

const deprecations = entries.filter(log => log.entry.source === 'deprecation').map(log => {
// HTML deprecations will have no url and no way to attribute to a specific line.
let source = null;

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

undefined should work (and hopefully allows getting rid of the null mentioned in another comment)

Comment thread types/audit-details.d.ts
Comment thread lighthouse-core/audits/seo/font-size.js
Co-Authored-By: Brendan Kenny <bckenny@gmail.com>
This reverts commit 30a7daf.
},
{
"source": "deprecation",
"value": "/deep/ combinator is no longer supported in CSS dynamic profile.It is now effectively no-op, acting as if it were a descendant combinator. /deep/ combinator will be removed, and will be invalid at M65. You should remove it. See https://www.chromestatus.com/features/4964279606312960 for more details."

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

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

this message is missing a space so i fixed it: https://chromium-review.googlesource.com/c/chromium/src/+/1790201

@paulirish

Copy link
Copy Markdown
Member

@brendankenny can you take a look

@paulirish

Copy link
Copy Markdown
Member

@brendankenny we're gonna merge tomorrow, FYI

Comment thread types/audit-details.d.ts
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.

report(font-size): linkify selectors in devtools

6 participants