Site Kit encountered an error: Error: Failed to construct ‘URL’: Invalid URL

Bug Description

After updating to WordPress 5.8 @westonruter is encountering the following dashboard error appeared when accessing the the primary Site Kit screen. (WP support forum topic)

Site Kit encountered an error

Failed to construct 'URL': Invalid URL

    in DetailsPermaLinks
    in Component
    in div
    in td
    in tr
    in tbody
    in table
    in div
    in ReportTable
    in div
    in div
    in TableOverflowContainer
    in div
    in div
    in Widget
    in WithWidgetSlug(Widget)
    in DashboardPopularPagesWidget
    in WhenAnalyticsActive(DashboardPopularPagesWidget)
    in WidgetRenderer
    in div
    in Cell
    in WidgetCellWrapper
    in div
    in Row
    in div
    in div
    in Grid
    in WidgetAreaRenderer
    in div
    in WidgetContextRenderer
    in DashboardApp
    in GoogleSitekitDashboard
    in RestoreSnapshots
    in ErrorHandler
    in Root

This error remans when revisiting the Site Kit Summary dashboard widget.

One possible cause could be additional plugins using the Google Charts library, similar to other JS errors as per #3132.

We did encounter the same error previously in support (#1855) although this occurred for the impacted using during AdSense setup, with no further details provided or instances reported.

There are also references in the Lighthouse repository of the same specific error although as @westonruter pointed out the stack trace points includes DashboardPopularPagesWidget and WhenAnalyticsActive references.

Additional Context

• Site Kit 1.37.0.
• Site Health information provided
• Standard mode AMP website
• Unreproducible in support when upgrading to 5.8 on a standard AMP site (without using all the same plugins)
• Support forum topic

---

Do not alter or remove anything below. The following sections will be managed by moderators only.

Acceptance criteria

• Site Kit calls instantiating a new URL in JS should be wrapped in a “try-catch” block if the value may not be a valid URL.
  • In case of an error an appropriate fallback should be used, e.g. an empty string or false/null.
• While it would technically be safest to do it everywhere in production code, we should at least do it in instances where the value passed to it does not come from within Site Kit, i.e. it comes from a Google API.
  • We can reliably assume that e.g. a siteURL value from Site Kit or location.href from the browser are valid URLs/paths.
  • Any URL checked with isURL from @wordpress/url is also valid because it does the same check internally
  • However we cannot reliably assume that all values from external APIs like Search Console, Analytics, or AdSense are valid URLs/paths.

Implementation Brief

The getURLPath and getFullURL utilities inside assets/js/util/urls.js need to be refactored as follows.

getURLPath

• Wrap the call to new URL in a try-catch block
• Inside the catch, return null
• Inside each consumer, refactor the logic at the getURLPath callsite, so that if it is falsey the path is not appended to the report arguments. For example, in DashboardAllTrafficWidget:

  // Before:
    if ( entityURL ) {
    	reportArgs[ 'explorer-table.plotKeys' ] = '[]';
    	reportArgs[ '_r.drilldown' ] = `analytics.pagePath:${ getURLPath(
    		entityURL
    	) }`;
    }
  // After:
    const path = !! entityURL && getURLPath( entityURL );
    if ( path ) {
    	reportArgs[ 'explorer-table.plotKeys' ] = '[]';
    	reportArgs[ '_r.drilldown' ] = `analytics.pagePath:${ path }`;
    }
  

  You’ll need to update the following files:

  assets/js/modules/analytics/components/dashboard/DashboardBounceRateWidget.js
  80:			? `analytics.pagePath:${ getURLPath( url ) }`
  
  assets/js/modules/analytics/components/dashboard/DashboardAllTrafficWidget/index.js
  188:		reportArgs[ '_r.drilldown' ] = `analytics.pagePath:${ getURLPath(
  
  assets/js/modules/analytics/components/dashboard/DashboardSearchVisitorsWidget.js
  101:		drilldowns.push( `analytics.pagePath:${ getURLPath( url ) }` );
  

• Update the unit tests for this function

getFullURL

• Wrap the call to new URL in a try-catch block
• Inside the catch, return a string which is a concatenation of the two params, i.e. siteURL + path
• Update the unit tests for this function

Test Coverage

• Unit tests for the two utilities should be updated as described above.

Visual Regression Changes

• None anticipated.

QA Brief

• Check getURLPath and getFullURL functions to make sure that they wrap new URL(...) calls with try/catch block.
• Check getURLPath function usage to verify that all calls account for possible NULL results.

Changelog entry

• Fix a potential error due to report data associated with an invalid URL.

[westonruter]

@eugene-manuilov Here you go: https://github.com/google/site-kit-wp/issues/4036

[felixarntz]

@bethanylang @aaemnnosttv @westonruter I’ve defined the ACs for this issue around fixing the JS error, where our code should be more defensively written. However, the weird situation with double slashes would still be a problem - however, I don’t think we should add logic to specifically fix double slashes, since that would open a can of worms around resolving any sort of potential weirdness with URLs stored in Analytics. Any idea why those double-slashed URLs could happen? I can’t imagine how that is caused by Site Kit since we merely inject the Analytics snippet 🤔