Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

chore(webkit): update error stack parsing and related system tests #23730

Merged
merged 34 commits into from Sep 12, 2022

Conversation

tbiethman
Copy link
Contributor

@tbiethman tbiethman commented Sep 8, 2022

User facing changelog

N/A

Additional details

WebKit error stacks currently have a number of documented issues, resulting in stack traces that aren't very helpful:

https://bugs.webkit.org/show_bug.cgi?id=86493
https://bugs.webkit.org/show_bug.cgi?id=243668
https://bugs.webkit.org/show_bug.cgi?id=174380

Screen Shot 2022-09-08 at 11 12 28 AM

This PR updates WebKit stack lines with some placeholder function/location values, which makes them more readable (if not more functional) and allows us to better parse them for presentation within the reporter and snapshot normalization. We are using <unknown> in the existing parsing logic when function names/locations could not be determined and I continued that here, but we could use something more verbose if it would be helpful.

It's important to note that the lack of call locations in these stacks makes a lot of our existing strategies for stack inspection/replacement much harder (if not impossible) to implement. A number of changes have recently landed in WebKit that should improve these stacks, at least so far as removing a lot of these internal stack items that this PR is working with. But the full impact of these changes (and the timeline for their inclusion in a new playwright-webkit release) is yet to be determined.

Steps to test

  • Open project of choice in WebKit
  • Update spec to fail (throw error in hook, expect(true).to.eq(false), throw uncaught error in fixture, etc.)
  • View stack trace of error, you shouldn't see any lonesome "@" symbols or stack entries missing a function name or location entirely

How has the user experience changed?

Before:

Screen Shot 2022-09-07 at 11 58 14 AM

After:

Screen Shot 2022-09-08 at 10 26 11 AM

PR Tasks

  • Have tests been added/updated?
  • [n/a] Has the original issue (or this PR, if no issue exists) been tagged with a release in ZenHub? (user-facing changes only)
  • [n/a] Has a PR for user-facing changes been opened in cypress-documentation?
  • [n/a] Have API changes been updated in the type definitions?

@cypress-bot
Copy link
Contributor

cypress-bot bot commented Sep 8, 2022

Thanks for taking the time to open a PR!

@flotwig flotwig mentioned this pull request Sep 8, 2022
21 tasks
errStack = errStack.replaceAll(webkitStackLineRegex, (match, ...parts: string[]) => {
// We patch WebKit's Error within the AUT as CyWebKitError, causing it to
// be presented within the stack. If we detect it within the stack, we remove it.
if (parts[0] === '__CyWebKitError') {
Copy link
Contributor

Choose a reason for hiding this comment

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

Is this because it's showing up in the stack trace of every new Error? Should we just not name the function then?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I went back and forth on this. If we don't name it, it'll still render here, just as yet another anonymous '' function. Given the frequency with which it'll be presented (for any uncaught exception thrown by the AUT), I figured its presence in the stacks might be confusing, named or not. But I could understand the argument that removing it is an improper obfuscation of what is actually being executed?

Copy link
Contributor

Choose a reason for hiding this comment

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

hmm, yeah... maybe we just oughtta name it Error, then. This seems fine too. Not too big an issue for experimental.

@cypress
Copy link

cypress bot commented Sep 8, 2022



Test summary

4755 0 370 0Flakiness 1


Run details

Project cypress
Status Passed
Commit 928ca9d
Started Sep 12, 2022 8:22 PM
Ended Sep 12, 2022 8:38 PM
Duration 15:51 💡
OS Linux Debian - 11.3
Browser Electron 102

View run in Cypress Dashboard ➡️


Flakiness

cypress/e2e/e2e/origin/commands/querying.cy.ts Flakiness
1 cy.origin querying > .get()

This comment has been generated by cypress-bot as a result of this project's GitHub integration settings. You can manage this integration in this project's settings in the Cypress Dashboard

@rachelruderman
Copy link
Contributor

Ahhhhhh I also have an open PR #23575 that messes with stack_utils, MAY THE GIT MERGE BEGIN!! Since my stuff is annoying and a lil complicated and I know how to test it, let's merge yours first and I'll figure out the conflict 🥲 ⚔️

@tbiethman tbiethman merged commit 405e7f7 into develop Sep 12, 2022
@tbiethman tbiethman deleted the tbiethman/webkit-stacks-pr branch September 12, 2022 20:40
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants