-
Notifications
You must be signed in to change notification settings - Fork 9.3k
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
Conversation
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? |
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. |
Ooooooo, that sounds like it's worth its weight in gold :) |
It's been awhile since I've used I haven't messed with this in particular, but maybe try getting a super simple |
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. |
@patrickhulce now that I think of it, I'm not convinced Seems simpler to open the viewer via |
9468ee0
to
92c3baf
Compare
Alright, I'm fine with content script approach. Feel free to clean up and make legit for that method then :) |
clients/extension/scripts/popup.js
Outdated
@@ -30,9 +30,41 @@ const NON_BUG_ERROR_MESSAGES = { | |||
' with http:// or https://.', | |||
}; | |||
|
|||
const subpageVisibleClass = 'subpage--visible'; | |||
const PSI_KEY = 'AIzaSyAjcDRNN9CX9dCazhqI4lGR7yyQbkd_oYE'; |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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
actually, let's just simplify this whole thing and have the content script call PSI itself. |
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()); |
There was a problem hiding this comment.
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.
|
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 |
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 |
There was a problem hiding this 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
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.. |
@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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
NICE
opacity: 0.74; | ||
color: currentColor; | ||
.button--generate { | ||
cursor: pointer; | ||
font-family: 'Roboto', Arial, sans-serif; |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM 😢
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'; |
There was a problem hiding this comment.
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
@patrickhulce I expected the referrer to be |
There was a problem hiding this 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.
Don't watch |
Huge step here. Great work @connorjclark |
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 viachrome.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 viachrome.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.