core(user-flow): support aborting pending navigations

[ChristopherPHolder]

Summary

Introduces a way to gracefully dispose of ongoing wait for conditions in Userflow navigation audits.

This allows programatic usage to handle failed navigations without having to await for wait for conditions to throw timeout errors.

It also automatically handles disposal of the conditions when the puppeteer page is closed.

Example usage:

import { writeFileSync } from 'fs';
import puppeteer from 'puppeteer';
import { startFlow } from 'lighthouse';

const browser = await puppeteer.launch();
const page = await browser.newPage();
const flow = await startFlow(page);

try {
  await flow.startNavigation();
  await page.goto('https://invalid-url.dev/');
  await flow.endNavigation();

  writeFileSync('report.html', await flow.generateReport());
} catch (error) {
  flow.dispose();
  console.error(error);
}

await browser.close();

Related Issues/PRs

CLOSES: #17065

[connorjclark]

looks promising!

could you also add something to docs/user-flows.md (perhaps under tips and tricks) about dispose()?

[connorjclark]

should check / use signal.throwIfAborted() too (source: https://developer.mozilla.org/en-US/docs/Web/API/AbortSignal#implementing_an_abortable_api)

[ChristopherPHolder]

Nice was not aware of that API.

I implemented the changes.

But I am not super sure it make sense tho, if a user calls dispose the navigation is will simply cancel the wait for conditions.

A user is not able to call startNavigation if the last navigation was not cleanedup successfully. That throws a clear error.

---

On a seperate note, i have phased another issue in the past where the audit took extremely long because the page was polling. So the network and cpu were never really quiet.

In theory i can dispose of the await conditions when i see the element i want render on the page.

Kind of an abuse of the api tho...

Those things are edge cases and probably better to move forward and i open another issue if it becomes an issue again.