Cypress garbling input and failing to find Wax editors
(Issue first raised in this thread in Mattermost.) Cypress doesn't always seem to play nicely with Wax/ProseMirror when attempting to select/clear/type into a Wax editor. Focus and caret position change erratically, causing text to become garbled, and at times Cypress is note even able to find a specified .Prosemirror
element via CSS selector.
This was observed when a cypress test failure started affecting all MRs, and the main branch:
The failure was in elife/manuscripts_page_spec.cy.js
. I was intermittently able to repeat this locally, though sometimes the test ran fine. There are four wax editors in the eLife submission form, and the test was attempting to select each in turn and type into it. Sometimes this worked fine but sometimes the focus would change rapidly between different wax editors during typing, and the fourth editor would not be found at all for some keystrokes. Text was garbled:
I wondered if ProseMirror was making brief modifications to the rendered elements, particularly regarding the ProseMirror
class our CSS selector relied on. We were using e.g. cy.getByClass('ProseMirror').eq(3)
to find the fourth ProseMirror element.
But even if I changed the selectors to something that ought to be totally unambiguous, such as cy.get('[data-testid="submission.review1"] > div > [contenteditable="true"]')
, it still jumped between Wax fields while typing and garbled the text.
While cypress is trying (and failing) to find the last wax field (cy.getByClass(SUBMISSION_FORM_INPUT_BOX).eq(3)
), a different wax field has a rapidly flickering border, suggesting that focus is changing very rapidly.
Because these tests had started failing fairly consistently in the pipelines from a specific date, I tried to replicate the failure on older checkpoints whose tests had previously passed. I was able to replicate the failure intermittently on a couple of older checkpoints where the same test had previously passed.
I tried several approaches to fix this behaviour, including feeding in text by passing low-level key events to the browser's active element. But nothing I tried seemed reliable. Failures were less frequent if I didn't try to clear existing text before typing, but failures still occurred.
I ended up disabling the test because I'd spent too much time on it, but I am not confident that similar intermittent failures won't affect other wax editors (or other controls?).