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

clients: retire extension; replace with PSI launcher #9193

Merged
merged 94 commits into from
Oct 26, 2019

Conversation

connorjclark
Copy link
Collaborator

@connorjclark connorjclark commented Jun 13, 2019

fixes #8690

Throwing up this draft to get some feedback on the Chrome extension API / viewer interaction. help, extension noob here.

At first, I attempted to do exactly what the "Open in Viewer" feature does - which is, open the viewer, the viewer sends a message to its self.opener, and the original report page responds with the LHR. In Chrome extension land, I figured the equivalent would be to make use of "externally_connectable", which allows the viewer to connect to the extension via chrome.runtime.connect. On connect, the extension could respond with the LHR. This worked up to the connection point, but any message the extension sent back was never received by the viewer (and caused no errors). I couldn't figure out why, so I moved on to the next approach.

What I went with now is: a background script opens the viewer via chrome.tabs.create and sends the LHR via chrome.tabs.sendMessage. The content script (configured to load at document_start) receives this message, and simply posts it to the window, allowing the viewer to receive the LHR. Does this seem like the best approach?

I did try to do the above without any background script (just open the viewer from popup.js), but the message would never reach the content script.


image
image

image

@brendankenny
Copy link
Member

brendankenny commented Jun 13, 2019

we bundle the report generator for just about everything now, would it be simpler to just do that for the extension as well and skip all the message passing stuff?

@connorjclark
Copy link
Collaborator Author

We could bundle the renderer. If we don't, and lean on the viewer, we get the extra bonus of not needing to update the extension every release. Whatever that's worth.

@patrickhulce
Copy link
Collaborator

we get the extra bonus of not needing to update the extension every release

Ooooooo, that sounds like it's worth its weight in gold :)

@patrickhulce
Copy link
Collaborator

It's been awhile since I've used externally_connectable but I feel like this should be the most straightforward. I've definitely done something like this in the past.

I haven't messed with this in particular, but maybe try getting a super simple sendResponse for chrome.runtime.sendMessage working? 🤷‍♂

@connorjclark
Copy link
Collaborator Author

I can try once more, but the commented out block of code was my attempt at that. Perhaps I skipped over something the first time. I'll try again.

@connorjclark
Copy link
Collaborator Author

connorjclark commented Jun 17, 2019

@patrickhulce now that I think of it, I'm not convinced externally_connectable is the better option, even if it happens to work, so I'll defer trying again unless convinced.

Seems simpler to open the viewer via chrome.tabs.create (thus providing the necessary connection via the tabId) than to require the viewer to reach out to the extension (which would require ?utm_source=extension so the viewer knows to use chrome.runtime.connect + would need to know the extension id, making local development annoying).

@patrickhulce
Copy link
Collaborator

Alright, I'm fine with content script approach. Feel free to clean up and make legit for that method then :)

@@ -30,9 +30,41 @@ const NON_BUG_ERROR_MESSAGES = {
' with http:// or https://.',
};

const subpageVisibleClass = 'subpage--visible';
const PSI_KEY = 'AIzaSyAjcDRNN9CX9dCazhqI4lGR7yyQbkd_oYE';
Copy link
Collaborator

Choose a reason for hiding this comment

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

is this an extension-specific key?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

yeah just forgot to add to the query

@connorjclark
Copy link
Collaborator Author

actually, let's just simplify this whole thing and have the content script call PSI itself.

@connorjclark
Copy link
Collaborator Author

actualllly, we can circumvent the entire message passing / extension stuff if we just bake loading from PSI into the viewer.

}
});

return fetch(psiUrl.href).then(res => res.json());
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Building script doesn't allow for es6, hence no async/await here. It also injects some Promise polyfills (hey ... we don't like that anymore, right?), so it seems like a larger issue for another day.

@brendankenny
Copy link
Member

  • The viewer part would be a good candidate for splitting into a separate PR
  • We don't really have tests of our bundles after the extension goes away. I'm not sure what we should do about that... https://bugs.chromium.org/p/chromium/issues/detail?id=966721 would help, but would only run on rerolls to DevTools. Puppeteer + the LR bundle?

@brendankenny
Copy link
Member

brendankenny commented Jun 18, 2019

The viewer part would be a good candidate for splitting into a separate PR

Also, this is getting pretty close to web.dev/measure territory, or https://developers.google.com/speed/pagespeed/insights/ for that matter. Why do we have those again? :D

@connorjclark
Copy link
Collaborator Author

connorjclark commented Jun 18, 2019

The viewer part would be a good candidate for splitting into a separate PR

Also, this is getting pretty close to web.dev/measure territory, or developers.google.com/speed/pagespeed/insights for that matter. Why do we have those again? :D

close...but not quite yet. web.dev lacks PWA and PSI is only performance, so until one of those changes seems like viewer is a good way to go

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.

at least wanted to flush these few before I forget for the millionth time

clients/extension/scripts/popup.js Outdated Show resolved Hide resolved
clients/extension/scripts/popup.js Outdated Show resolved Hide resolved
@patrickhulce
Copy link
Collaborator

I'm getting an error when trying out the extension this time around, is this expected?

image

@connorjclark
Copy link
Collaborator Author

connorjclark commented Oct 23, 2019

Patrick, I don't know why it's not working for you locally, but it works here: https://googlechrome.github.io/lighthouse/viewer/?psiurl=https://www.example.com&locale=es

I think we may have removed the localhost referral exception. I don't test it with a local viewer anymore.

EDIT: oh you're not using a local viewer. IDK. works for me..

@patrickhulce
Copy link
Collaborator

@connorjclark yeah I'm not using the local viewer, the message about the referrer seems real. If I visit the URL directly (https://googlechrome.github.io/lighthouse/viewer/?psiurl=http%3A%2F%2Fexample.com%2F&strategy=desktop&category=accessibility&category=seo&category=pwa&utm_source=lh-chrome-ext), it works just fine, but when it gets opened by the extension it fails.

Copy link
Member

@paulirish paulirish left a comment

Choose a reason for hiding this comment

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

NICE

clients/extension/images/lh_logo.svg Outdated Show resolved Hide resolved
clients/extension/popup.html Outdated Show resolved Hide resolved
clients/extension/styles/lighthouse.css Outdated Show resolved Hide resolved
opacity: 0.74;
color: currentColor;
.button--generate {
cursor: pointer;
font-family: 'Roboto', Arial, sans-serif;
Copy link
Member

Choose a reason for hiding this comment

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

i think this is duplicated by the html,body font already here

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

button has a default font-family. but should use the variable here.

Copy link
Member

@brendankenny brendankenny left a comment

Choose a reason for hiding this comment

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

LGTM 😢

@brendankenny
Copy link
Member

@connorjclark yeah I'm not using the local viewer, the message about the referrer seems real. If I visit the URL directly (https://googlechrome.github.io/lighthouse/viewer/?psiurl=http%3A%2F%2Fexample.com%2F&strategy=desktop&category=accessibility&category=seo&category=pwa&utm_source=lh-chrome-ext), it works just fine, but when it gets opened by the extension it fails.

we need to make sure this is resolved, though, whether it's by referrer or whatever is going on. A pptr extension test would be handy for that sort of thing :P

@@ -5,58 +5,10 @@
*/
'use strict';
Copy link
Member

Choose a reason for hiding this comment

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

FWIW we should probably rename this file to be popup-entry.js or whatever so it's the same clear signal that it's the root of a bundle like the others. I don't feel strongly about it today, though

@connorjclark
Copy link
Collaborator Author

@patrickhulce I expected the referrer to be https://googlechrome.github.io/lighthouse/viewer/ but that error message says https://googlechrome.github.io/ is used. I've added the latter to the whitelist. Does it work now?

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.

Does it work now?

Like budah!

LGTM! farewell extension, you served us well.

@brendankenny
Copy link
Member

Don't watch

@brendankenny brendankenny merged commit 2953c0c into master Oct 26, 2019
@brendankenny brendankenny deleted the simplify-extension branch October 26, 2019 17:59
@brendankenny
Copy link
Member

Huge step here. Great work @connorjclark

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.

Deprecate the Lighthouse Chrome extension
7 participants