fix: Fix issues with stack traces and command log in Chrome 99

[github-actions]

User facing changelog

Fixes multiple issues in Chrome 99:

• No longer throws an exception when attempting to display a Document or ShadowRoot in the Cypress command log.
• Stack traces were not reporting properly.

Additional details

Chrome 99 includes an updated version of v8, which breaks our stack trace trimming. A fix is included with commentary on why the change is needed.

It also updates the behavior around enumerating properties of StyleSheets. There's no good reason we should be doing this at all though.

How has the user experience changed?

In older versions, when a ShadowRoot was rendered to the command log, it would treat it as a Javascript object, and enumerate its properties, looking like this:

After this change, it is treated like an HTML element, resulting in displaying this in the command log:

The same is true for a Document. They now render their inner html to the command log rather than a verbose enumeration of their properties (which includes the innerHTML).

[cypress-bot]

Thanks for taking the time to open a PR!

• Create a Draft Pull Request if your PR is not ready for review. Mark the PR as Ready for Review when you're ready for a Cypress team member to review the PR.
• Become familiar with the Code Review Checklist for guidelines on coding standards and what needs to be done before a PR can be merged.

[cypress]

---

Test summary

19177 • 0 • 218 • 0 • 1

---

Run details

Project	cypress
Status	Passed
Commit	d2cabd8
Started	Feb 10, 2022 8:14 AM
Ended	Feb 10, 2022 8:25 AM
Duration	11:39 💡
OS	Linux Debian - 10.10
Browser	Multiple

View run in Cypress Dashboard ➡️

---

Flakiness

	cypress/integration/cypress/proxy-logging_spec.ts		1
1	Proxy Logging > request logging > xhr log has response body/status code

---

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

[BlueWinds]

When we start recursively inspecting objects, listing out their properties, this can include elements with references to objects like window and document. And in Chrome 99, when we iterate over the properties of document.adoptedStyleSheets, it throws an error.

Ultimately though, there's no reason we should be looking over every property of a Document. In the same way we already abort for HTMLElements above, I added an early exit for ShadowRoot and Document, returning a string of their HTML rather than recursively enumerating their properties. This should be a minor performance win, saving on hundreds of calls through formatValue in cases where we pass in window, document or other global-ish objects that aren't literal HTMLElements.

No tests have been added, because the output of this function is already comprehensively tested - dozens of tests failed in Chrome 99 before the changes to this file.

[emilyrohrbough]

🥳 yay to improved performance!

[flotwig]

Ran bisect-builds against these changes to find what broke between this beta and stable:

bisect-chrome-builds.py --good=950365 --bad=961656 --command="zsh -c 'cd `pwd`/packages/driver && yarn cypress:run --spec **/type_spec.js --browser %p'" --archive=linux64 --use-local-cache --not-interactive --verify-range

Bad revision: 950808
You are probably looking for a change made after 950807 (known good), but no later than 950808 (first known bad).
CHANGELOG URL:
  https://chromium.googlesource.com/chromium/src/+log/eef8f91d45d7b9d36f0e3cd1b6cd33d3bedff113..e5b482aff3e9e0031527108c7131861ed2640dcc

This is the only commit that changed between good and bad revisions: https://chromium.googlesource.com/chromium/src/+/e5b482aff3e9e0031527108c7131861ed2640dcc

Convert adoptedStyleSheets to use ObservableArray

This CL converts adoptedStyleSheets from a FrozenArray to the
new ObservableArray. This is per the new spec [1]. It should be
backwards compatible, and will allow mutation of adoptedStyleSheets
in place using regular array methods like .push():

  document.adoptedStyleSheets = [sheet1, sheet2];
  document.adoptedStyleSheets.push(sheet);
  ...etc...

Intent to ship:
https://groups.google.com/a/chromium.org/g/blink-dev/c/8p7QvGn3Ezo

[1] https://drafts.csswg.org/cssom/#extensions-to-the-document-or-shadow-root-interface

Bug: 1201744
Bug: 1236777
Change-Id: [Iacbf66a38c0abd477b5628224c97bec9f8a317e4](https://chromium-review.googlesource.com/#/q/Iacbf66a38c0abd477b5628224c97bec9f8a317e4)
Cq-Do-Not-Cancel-Tryjobs: true
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3270424
Reviewed-by: Yuki Shiino <yukishiino@chromium.org>
Reviewed-by: Raphael Kubo Da Costa <raphael.kubo.da.costa@intel.com>
Reviewed-by: Rune Lillesveen <futhark@chromium.org>
Commit-Queue: Mason Freed <masonf@chromium.org>
Cr-Commit-Position: refs/heads/main@{#950808}

Apparently it's supposed to be a backwards-compatible change. I wonder why it broke our usage here. Do you think we should file a bug with Chromium?

LGTM otherwise

[BlueWinds]

Apparently it's supposed to be a backwards-compatible change. I wonder why it broke our usage here. Do you think we should file a bug with Chromium?

LGTM otherwise

I'm fairly convinced this is a browser bug. After spending some time on it, I've reduced it to the following repro case:

for (var a in document.adoptedStyleSheets) {}

This errors on chrome-beta 99, and succeeds on chrome 98. I'll open a bug with Chrome on the subject.

With that said, we should still work around it for now - the change I applied to get the tests passing is a good one to have in place even if chrome fixes the issue at some point.

[flotwig]

I think this should also be added to the release and changelog, to call out that we fixed a bug with versions of Chrome after 99.

[BlueWinds]

Opened https://bugs.chromium.org/p/chromium/issues/detail?id=1295410. Will update issue to include user-facing changelog.

[emilyrohrbough]

Does this change with chrome has impact on the implementation of the cy.shadow() command?

[BlueWinds]

So no tests in the shadom dom specs required changing, but there is a change in the way it's displayed. I'm updating the PR description with details, since it's user-facing.

Unintentional, but I think the new version is much cleaner, so looks like a feature rather than a bug to me!

[emilyrohrbough]

I'm not understanding this comment 100%, which one is the trimmed one?
Above on line 142, we are setting userInvocationStack = newErr.stack so regardless of this check, won't the stack be the newError stack?

[BlueWinds]

captureStackTrace modifies the error object in place. So for example, beforehand, newErr.stack might will be 15 lines. Then we call captureStackTrace(newErr, captureUserInvocationStack), and now newErr.stack is only 10 lines long.

This guard is against the case - in Chrome 99 - where it was already only two lines, and gets reduced to one. Eg, it might be

Err: Foobar is bad!
  at (localhost:3500/cypress/stuff/myspec.js:54:12)

and it gets trimmed down to

Err: Foobar is bad!

I'm not 100% sure what caused the changed behavior of captureStackTrace in chromium 99, but the first stack trace is far more useful than the second.

[emilyrohrbough]

ahhh the fact captureStackTrace modifies this as well was the part I was missing! Thanks for the extra info.

[jennifer-shehane]

Yah, we'll have to put these changes in the changelog for sure.

[cypress-bot]

Released in 9.5.0.

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