-
Notifications
You must be signed in to change notification settings - Fork 9.4k
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
misc: puppeteer script to test a page from devtools #12145
Conversation
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.
test>next<import @devtools-bot
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.
very clever, I like it! :D
const page = await browser.newPage(); | ||
|
||
// Cut off JS for initial page navigation. | ||
// This step is unnecessary for every page I tried except https://cnn.com. |
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.
What happens when you allow JS? This is rather surprising to me.
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.
LH never starts because cnn takes too long to load. I believe the page's scripts are hogging the main thread so much that startLighthouse
never runs successfully.
Every other page I tested didn't need this step, but disabling JS still decreased the startup time for those pages.
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.
Yikes. I don't love doing this because if we can't run Lighthouse because a page is so busy, it might be indicative of our users not being able to run Lighthouse because a page is too busy.
Finding the "Lighthouse doesn't work in scenario X" is actually the point of creating a DevTools repro script, so perhaps we've already found our first bug :)
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.
Good point, I took another look and it turns out I was overthinking the problem. The script just blocks on await page.goto(...)
and never gets to the part where it tries to start LH.
Instead of disabling javascript to get the page to load faster, I just took out the await
on page.goto(...)
.
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.
Update: Trying to start LH immediately after navigation starts sometimes causes DT to hang on "Lighthouse is warming up..." forever.
Changed this to wait for DOMContentLoaded
before trying to start LH.
|
||
fs.writeFileSync('latest-run/lhr.json', remoteLhrResponse.result.value); | ||
|
||
await session.send('Runtime.disable'); |
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 this have a particular effect you noticed? fine to leave in, I just wouldn't expect it to do anything if we're shutting down the entire browser immediately after :)
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.
No effect that I noticed.
FWIW I plan to update this script to test multiple urls. Script would open a new page for each test and close the page after, but browser remains open the entire time. Do you think this line would have an effect then?
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.
If you're still closing the page I wouldn't expect it to have an effect. I suppose it's slightly more plausible there's some memory leak in Chromium browser process no one has discovered before, but still seems unlikely to affect us.
const pageSession = await page.target().createCDPSession(); | ||
await pageSession.send('Page.enable'); | ||
pageSession.once('Page.domContentEventFired', resolve); | ||
page.goto(process.argv[2]).catch(err => err); |
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.
Can you process args at the top of the file, and leave a comment (like in the other file) on how to run this?
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.
Added usage comment, wound up removing the usage of cli args in favor of stdin.
Yeah, that seems workable. We can think about it at some point. |
|
||
const startLighthouse = ` | ||
(() => { | ||
UI.ViewManager.instance().showView('lighthouse'); |
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 working for you locally still? When I run it it seems like this line isn't succeeding (it's stuck on the elements panel)
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.
It's working fine for me on the latest Canary, but I was having issues earlier with a custom DT frontend.
Can you try opening DT on DT and running this line manually?
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.
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.
Can you do const ViewManager = UI.ViewManager.ViewManager || UI.ViewManager; ...
so it works in stable and canary?
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.
Update: The issue here was that CHROME_PATH
wasn't set, so puppeteer defaulted to M78 which uses the "Audits" panel instead of the "Lighthouse" panel.
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've upgraded our puppeteer dep: #12284
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.
bulk of this seems as good as I remember! :)
.option('o', { | ||
type: 'string', | ||
default: 'latest-run/devtools-lhrs', | ||
}).alias('o', 'output-dir') |
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.
not a big deal, but I find it to be more readable for non-authors when the option is the typical JS camelCase version and the alias is the letter. You still get the same support for -o
, --output-dir
and --outputDir
but it's much clearer in the JS when you use argv.outputDir
and it matches the explicit option :)
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'm a little conflicted here.
I think you're right that the readability is better, but I would also prefer to keep --custom-devtools-frontend
in kebab case because it matches the corresponding flag used on the chrome instance. It's probably better to keep the case for these two flags the same.
I think I will leave this as as for now.
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.
that's fine. fwiw I'd still take argv['custom-devtools-frontend']
over argv.d
😉
Add a new puppeteer script to run LH from DT inspector. This script is better than the old web test one for a few reasons:
Still TODO:
Old script:
#11539
#11751