addEventListener for "message" not relayed from browser extension

[kasbah]

Current behavior

When testing a page where a browser extension content script sends a message via window.postMessage and a page is listening via window.addEventListener("message", ...) Cypress does not pass on this message.

Desired behavior

Cypress should pass on these events.

Test code to reproduce

https://github.com/kasbah/cypress-add-event-listener-repro

git clone https://github.com/kasbah/cypress-add-event-listener-repro
cd cypress-add-event-listener-repro
npm ci
npm serve

npm run test

To confirm that a similar test passes using playwright you can do:

npm run test-pw

Cypress Version

10.1.0

Other

May be related to #1567

[lmiller1990]

Hi!

I think there's a misunderstanding about how launchOptions.extensions works here, docs. This is for loading extensions into the browser Cypress is running in. I added a console.log into the content-script:

You can see this is logged immediately - this is executed as soon as the browser (which Cypress is running in) opens. If i then navigate to the spec:

We add the event listener - this is added to the <iframe> that your spec runs in. This is what is happening here:

1. extension is added to the main window
2. executes immediately
3. run spec
4. event added to the <iframe> which your application (localhost:3000) is rendered.

What are you trying to do? Are you looking to write E2E tests for your web extension? This is definitely something that you should be able to do with Cypress, but in a different fashion. Depending on what your extension is, you could host it on a server (say localhost:3000) and visit there using cy.visit - that should work as expected.

Check the events catalog - maybe something like this example might be closer to what you want, eg:

it('can listen', () => {
  cy.on('window:before:load', (win) => {
    win.addEventListener('...')
  })
})

If you can provide more insight into what you are trying to test, I can offer more suggestions.

[kasbah]

Hey, thanks for the detailed response. Indeed I am trying to test a browser extension. In this instance I am trying to test that a browser extension content-script is doing the right thing on a particular page. I'm struggling a bit with how I would do that by serving the extension up on localhost. Do you have any more links on that?

In case more details help: this is the actual test I've been writing so far using Playwright. It visits a page on our site and clicks the "Mouser" button, which only does something useful with the extension loaded. We use Cypress extensively (on kitspace-v2) so it'd be nice to stick with it for these tests.

[lmiller1990]

Right, I understand better now. When I suggested serving the extension locally, what I had in mind was that your extension is basically a mini web app (which it is, looks like a React app):

When I've made complex web extensions before, I've tested them by starting the dev server (eg yarn start) and my back-end API server (however you do it, for example yarn backend, navigated to it using cy.visit and testing it as if it's a isolated web app, using things like cy.intercept to assert API calls are made correctly. Now I better understand what you are doing here, I don't think this is really what you want, at least not here - we want to test the injected behavior of the plugin (which seems to add some custom event listeners to specific buttons? Is this correct?)

I had a better look into chrome extensions + Cypress, and we can load chrome extensions into the browser, the way you suggested - and since we change domain to match the iframe, I think your extension should be able to inject custom code into the app in the iframe, too.

My understanding here is you would like to test this in a true end-to-end fashion, with the actual extension packaged up and running in the browser. Navigating to a new tab is (currently) a limitation of Cypress. It is possible to change origin and follow a redirect in the same window using cy.origin.

Having said that, maybe we can still write tests with Cypress. The goal, in general, that the extension:

• injects some custom event listener on buttons
• when you click on a button, it makes an API call and pre-fills a cart
• then opens the page in a new tab?

Is this correct? We should be able to do all of this, except asserting against the new tab (limitation of Cypress, at least today). I tried this but I'm enchanting something unexpected:

I'd like to know why it isn't, at least, taking me to the correct tab (with the shopping cart). Is this the right code base? Can you point me to what exactly your chrome extension does in the background? I'd like to figure out what's going on here, since this should definitely be redirecting to the correct location, at least, based on my understanding.

[kasbah]

Hey, it is the right code base indeed. It can currently take 3 seconds to register with the page which is why you aren't getting to the right page. You need to wait just over 3 seconds before clicking the button.

I realise that the way this extension currently works has some problems and is not the best way to achieve the desired behavior. This will be fixed in a re-write. It's part of why I'd like to have some e2e tests for the extension: to help with the re-write.

Unfortunately, in addition to all the e2e frameworks that I've tried not being that well set up to test extensions yet, I've hit another road block: in interacting with the external site during tests (mouser.com) we sometimes get flagged as a bot and get blocked. puppeteer-extra-plugin-stealth seems to be the best low-effort way to try and avoid this, but that means I need to use puppeteer I guess. I might have to give up on the idea of using e2e testing for this.

[lmiller1990]

Thanks for clarifying. I'll try and take another look at this, sometime this week. It seems like there's a few other blockers? I'm not sure I can prioritize this one right now, but I'm definitely interested in the general "testing extensions with Cypress" problem, so I'll try and loop back around to this later this week. Let me know if you come up with anything in the meantime.

As for the original issue - I am not sure we have a bug or any obvious actionable work to be done in the Cypress code base? Should we leave this open (which would imply we have a bug to fix) or would you be happy to close it (but continue the discussion)?