Browser Connect Options on Collect

Hey Chrome team,

Great work so far with well everything. 😅

I have come across a scenario which is probably worth a discussion. My Team and I were looking to use LighthouseCI alongside the Cypress testing framework. When using Cypress this allows us to mock requests fairly simply and manages all our visual, e2e and performance testing under one framework. We were originally using Lighthouse in Cypress until we wanted to start using LighthouseCI server and we felt it was best to try using the LighthouseCI client for a convenience.

Problem After playing around with the puppeteerLaunchOptions and debugging it became clear that LHCI will always create a browser when running tests. Since Cypress will create a browser we were wanting to point the lighthouseCI tests to this browser to benefit from the mocking etc.

From what I can tell there are no puppeteer connect options or code throughout the LighthouseCI project and I was wondering whether this feature could be considered? I’m not 100% of the test impact of connecting to a 3rd party managing a chrome browser. I have managed to get it run on my mac and the performance results don’t seem to change. Something worth thinking about though.

Possible Solution An ideal solution would look something like this:

{
  ci: {
    collect: {
      url: 'http://localhost:5000',
      puppeteerConnectOptions: {      
        browserWSEndpoint: 'ws://127.0.0.1:39749/devtools/browser/09a33306-8c38-421a-9077-74864b845141'
      },
    },
}

If this is not possible would you happen to have and docs or guidance for uploading lighthouse reports generated outside of lighthouseCI to LighthouseCI server? I think this would be our only other alternative.

Additional context Debugging Learnings: When having dumpio set we can see that when setting the same debugging port as the one in use by cypress causes a bind issue but fails silently(?) on my host machine and lighthouseCI is then able to connect to the existing cypress browser. This doesn’t happen in headless mode… And isn’t properly supported hence this feature request. See the attached video for more info (The “Random” user list is mocked). You can see LHCI will open a browser after Cypress does but this closes shortly after once the bind fails.

https://user-images.githubusercontent.com/2506718/108979726-db2e4200-7682-11eb-836e-d68335e51708.mp4

[patrickhulce]

@patrickhulce have you ever seen someone do something similar to this or is there a restriction I am just lacking context for?

I’m not sure what the “this” is in your sentence. Are you referring to request interception for mocking server responses during a Lighthouse run?

You’re going to run into issues with that because Lighthouse uses request interception itself to handle a few of its checks. It might work after https://github.com/GoogleChrome/lighthouse/issues/11313 work is finished, and you might be able to get it to work for a specific request that you need, but it isn’t officially supported yet so you’re sort of on your own there.

[joshuawootonn]

Yup that is what the this was referring to. Makes sense that there are conflicts between the interceptors. Thanks for the update!