report: handle invalid urls for source location items

[adrianaixba]

For #11261

Adds lh-link class to source-location render element. Needed to handle invalid URLs that didn’t create elements.

[googlebot]

Thanks for your pull request. It looks like this may be your first contribution to a Google open source project (if not, look below for help). Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

📝 Please visit https://cla.developers.google.com/ to sign.

Once you've signed (or fixed any issues), please reply here with @googlebot I signed it! and we'll verify it.

---

What to do if you already signed the CLA

Individual signers

• It's possible we don't have your GitHub username or you're using a different email address on your commit. Check your existing CLA data and verify that your email is set on your git commits.

Corporate signers

• Your company has a Point of Contact who decides which employees are authorized to participate. Ask your POC to be added to the group of authorized contributors. If you don't know who your Point of Contact is, direct the Google project maintainer to go/cla#troubleshoot (Public version).
• The email used to register you as an authorized contributor must be the email used for the Git commit. Check your existing CLA data and verify that your email is set on your git commits.
• The email used to register you as an authorized contributor must also be attached to your GitHub account.

ℹ️ Googlers: Go here for more info.

[adrianaixba]

@googlebot I signed it!

[googlebot]

CLAs look good, thanks!

ℹ️ Googlers: Go here for more info.

[connorjclark]

@adrianaixba you may wish to set your email for the Lighthouse repo (and all google git repos) to your google email: git config user.email <ldap>@google.com, which should avoid some troubles with CLA bot.

[connorjclark]

renderSourceLocation errors when _renderLink fails to create an anchor element, which only happens if item.url is an ill-formed URL or one of invalid protocol.

However, I'm having trouble understanding when that can happen, because if item.urlProvider === 'network', as is the case here, my understanding is that item.url must always be a valid URL of protocol http or https. This is set in just a handful of places [1], and I think each one is certain to come from a network record, thus must be a valid URL.

It's not trivial to see this, and clearly it's wrong as we've gotten an error report, so we should certainly guard against this in the details renderer. But I'd like to see an example of an erroring case so we can be sure that we are testing against the correct "bad url" here.

It'd help to find a reproduction case. I requested the issue filer to provide one #11261

[1]

[connorjclark]

We found the error'ing url to be a relative url, like /url/main.js. Can you update the "invalid url" in this test to be that?

I'd also suggest a truly invalid url, one that would throw an error for new URL(), like new URL('atx')

[paulirish]

i helped with finding a renderer-side solution here, so i'm biased. but this lgtm. 👍

agree that there's extra work to harden the internals so this won't happen. #11261 (comment)

[connorjclark]

LGTM!