Blurred Lighthouse Report Viewer box when launching Chrome extension

[awdltd]

The message in the loading page after launching Lighthouse via the Chrome extension has blurred styling (filter: blur(2px)) that makes the text difficult to read. It's not immediately clear why.

Element reads:

Lighthouse Report Viewer

To view a report: Paste its json or a Gist URL.
You can also drag 'n drop the file or click here to select it.

Element selector:

 .viewer-placeholder-inner.lh-loading {
    filter: blur(2px);
}

See screenshot below for how it displays:

This styling persists for the duration of Lighthouse waiting for the results (whilst LH is loading); the result page renders correctly.

The blurring is clearly intended to signify 'loading', and the content of the window is clearly meant to be disabled as a results (as a page has already been selected, and Lighthouse is waiting on the results) but the currently styling seems somewhat non-intuitive.

I would suggest that it would make more sense greying out the content (rather than blurring) and adding an appropriate cursor (e.g. cursor: not-allowed or cursor: wait).

The element is still interactive too, despite being blurred, which could add further confusion. Perhaps adding pointer-events: none too would avoid potential conflicts using the extension.

Provide the steps to reproduce

1. Click Lighthouse extension icon in Chrome (v100.0.0, Windows 10. Chrome 78)
2. Click 'Generate report' button
3. Message displayed in main window whilst waiting for results is blurred

What is the current behavior?

The introductory banner loads with blurred styling

What is the expected behavior?

For the box to not be blurred, and instead be fully legible and/or greyed out (and, if disabled, disable interactivity appropriately)

Environment Information

• Affected Channels: Extension
• Lighthouse version: 100.0.0.0
• Chrome version: 78.0.3904.97 (64-bit)
• Node.js version: n/a
• Operating System: Windows 10

[awdltd]

Thanks for updating the issue! Just a minor point to raise with the changes (if you want to re-open the issue, if you think it worth tackling).

Current changes

.viewer-placeholder-inner.lh-loading {
  filter: blur(2px) grayscale(1);
  pointer-events: none;
  cursor: wait
}

You have added the appropriate attributes (i.e. pointer-events: none and cursor: wait) though you have added these both to the same element (sorta my bad though sorry, during my suggestion that these attributes should both be considered I didn't clarify that they should be added to different, appropriately-nested elements).

The problem is, when you have pointer-events: none added to an element, all interactivity (including :hover) is ignored. Meaning that no related cursor will show when you mouseover the element, rendering the cursor: wait redundant.

Given the structure of the document is as so during load:

<div class="viewer-placeholder">
  <div class="viewer-placeholder-inner lh-loading">
    <div>...</div>
    <div>...</div>
  </div>
</div>

It might make more sense to do the following as a quick fix

.viewer-placeholder-inner.lh-loading {
  filter: blur(2px) grayscale(1);
  cursor: wait
}

.viewer-placeholder-inner.lh-loading > div {
  pointer-events: none;
}

Though I think it would perhaps be better still (if it's not too much faff) to apply the lh-loading class to the outer wrapper (viewer-placeholder) as this will give you more control over styling, and you won't need to rely on CSS direct-child selectors. So something like:

<div class="viewer-placeholder lh-loading">
  <div class="viewer-placeholder-inner">
    ...
  </div>
</div>

.viewer-placeholder.lh-loading {
  cursor: wait
}

.viewer-placeholder.lh-loading .viewer-placeholder-inner {
  filter: blur(2px) grayscale(1);
  pointer-events: none;
}

I appreciated that you are creating higher specificity here by nesting the viewer-placeholder-inner selector, but given that this is quite a specific action (which is unlikely to ever have any higher-precedent action) I think the increased specificity is not just acceptable, but actually beneficial.

Happy to do a PR if that helps?

[patrickhulce]

Thanks @awdltd a PR would be great! :)