Skip to content

Conversation

@AtofStryker
Copy link
Contributor

@AtofStryker AtofStryker commented Jan 14, 2025

Additional details

Automates firefox with WedDriver BiDi instead of Chrome Devtools Protocol.

With Chrome Devtools Protocol being deprecated in Firefox 129 and slated for removal in the Firefox browser, Cypress has made the decision to automate Firefox with WedDriver BiDi.

This PR gets the basics cut over to BiDi, mainly the server's middleware prerequest logic and association, along with being able to associate the Application Under Test (AUT)

Currently, this is only enabled automatically for Firefox 135 and up. This PR also only cuts over to BiDi what is absolutely necessary. The rest of the work can be handled in #30221. This also should not be a major impact to users as the automation client is abstracted.

See #30447 for more additional details

Steps to test

Unit tests are added/modified in the server package, but the best way to test is to run cypress against firefox 135 and greater on this branch. To make sure there aren't regressions with the CDP implementation for firefox 134 and below, we run the driver tests additionally on an older version of firefox

How has the user experience changed?

Webdriver BiDi is now the default automation client for Firefox version 135 and up. A warning will be printed to the console (regardless of Firefox version) if CDP is in use for Firefox:

Screenshot 2025-02-14 at 1 00 26 PM

We are also adding a snippet in the docs on the update. If needed, FORCE_FIREFOX_CDP can be set as an env variable to force CDP on. The current plan is for CDP support for Firefox to be removed in Cypress 15.

Screenshot 2025-02-14 at 2 07 56 PM

PR Tasks

@AtofStryker AtofStryker changed the base branch from develop to chore/update_wdio_deps January 14, 2025 15:15
@cypress
Copy link

cypress bot commented Jan 14, 2025

cypress    Run #60569

Run Properties:  status check passed Passed #60569  •  git commit a8e36860a4: update firefox warning
Project cypress
Branch Review feat/implement_bidi
Run status status check passed Passed #60569
Run duration 17m 55s
Commit git commit a8e36860a4: update firefox warning
Committer AtofStryker
View all properties for this run ↗︎

Test results
Tests that failed  Failures 0
Tests that were flaky  Flaky 2
Tests that did not run due to a developer annotating a test with .skip  Pending 77
Tests that did not run due to a failure in a mocha hook  Skipped 0
Tests that passed  Passing 5623
View all changes introduced in this branch ↗︎

Warning

No Report: Something went wrong and we could not generate a report for the Application Quality products.

@AtofStryker AtofStryker marked this pull request as draft January 15, 2025 15:43
@AtofStryker AtofStryker force-pushed the feat/implement_bidi branch 2 times, most recently from 6d48392 to ab077a7 Compare January 22, 2025 15:26
@AtofStryker AtofStryker force-pushed the feat/implement_bidi branch 2 times, most recently from 5264fcb to 8b3b779 Compare January 22, 2025 21:20
@AtofStryker AtofStryker force-pushed the feat/implement_bidi branch 6 times, most recently from 3d23335 to 534be08 Compare February 7, 2025 20:47
@AtofStryker AtofStryker force-pushed the chore/update_wdio_deps branch from 46edeb9 to 9c6e162 Compare February 10, 2025 18:02
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the header attachment is completely handled within the bidi_automation class

@AtofStryker AtofStryker changed the title feat: implement webdriver BiDi feat: implement webdriver BiDi for Firefox versions 135 and greater Feb 10, 2025
@AtofStryker AtofStryker force-pushed the chore/update_wdio_deps branch from 9c6e162 to 5219967 Compare February 10, 2025 20:41
@AtofStryker AtofStryker self-assigned this Feb 10, 2025
Base automatically changed from chore/update_wdio_deps to develop February 10, 2025 21:27
@AtofStryker AtofStryker force-pushed the feat/implement_bidi branch 3 times, most recently from af8f1cd to d605883 Compare February 10, 2025 22:16
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I know it's not currently typical for the middleware here, but can this be in a separate file and exported from request-middleware.ts? That conforms a little closer to SRP, and would be a good move forward for the middlewares here

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

exported from request-middleware or imported? I'm a bit hesitant to introduce a one off pattern here for a function so small, unless we refactor the middleware in a separate PR.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Both, considering how the default export from this file is used - but I think that pattern needs a larger look. Leave it for now!

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

these two conditionals can be combined

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

updated this in 279b7561ba

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh, I was thinking of combining the nested ifs, rather than the isCDPForced

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this spelled out in a spec somewhere? Just curious if we might need to know if this might change in the future. Do we have any firefox tests that would break in that case?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

in the Bidi spec or the cookie spec. I don't think they are in either. If it does change my guess is it wouldn't have an impact since we are only checking for the deviation. but that would mean the code would effectively be dead

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we need to unsubscribe to BIDI_EVENTS here as well?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We could but its a bit hard to accomplish. We could probably do it instance kill but the events effectively get unsubscribed when geckodriver and firefox are killed AFAIK

Copy link
Collaborator

@ryanthemanuel ryanthemanuel left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Couple of small questions and suggestions but looks good overall.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can't remember, did we talk about whether or not this would be considered a breaking change? Like if someone is intercepting a certain resource type but the types are different now so the intercept breaks.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We did briefly which was one of the rationales around deprecating the field. The idea that we are trying our best to map these 1:1 and the types be the same shouldn't make it a breaking change, but it's difficult to predict the behavior for each type. That being said I don't think its a breaking change but there could be bugs that we will need to fix. I feel confident on fetch and xhr types, but the fonts might be a little more nuanced which is in use as seen here. Worse case, if a bug is present with the mapping, the user can opt out with the FORCE_FIREFOX_CDP until we fix it

Copy link
Contributor

@mschile mschile Feb 21, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it doesn't but independently I think the type is wrong since its a string in both chrome and firefox. I can update it on the docs PR

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the types are actually correct here https://github.com/cypress-io/cypress/blob/develop/cli/types/cypress.d.ts#L107 but incorrect in the docs, so I added them to the docs PR cypress-io/cypress-documentation#6103

Copy link
Contributor

@mschile mschile left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks great overall! Added a couple questions.

@AtofStryker AtofStryker merged commit 5da0995 into develop Feb 24, 2025
135 of 137 checks passed
@AtofStryker AtofStryker deleted the feat/implement_bidi branch February 24, 2025 18:17
@cypress-bot
Copy link
Contributor

cypress-bot bot commented Feb 25, 2025

Released in 14.1.0.

This comment thread has been locked. If you are still experiencing this issue after upgrading to
Cypress v14.1.0, please open a new issue.

@cypress-bot cypress-bot bot locked as resolved and limited conversation to collaborators Feb 25, 2025
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

misc: Connect WebDriver BiDi client to Firefox inside Cypress to replace CDP / Classic WebDriver

4 participants