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

fix: always set percy-data attributes when serializing #1450

Closed
wants to merge 7 commits into from

Conversation

nilshah98
Copy link
Contributor

@nilshah98 nilshah98 commented Dec 1, 2023

context-

  • when we serialize dom, we check if data-percy-element-id is already available, if yes we do not add a new one.
  • this data-percy-element-id attribute is used to create url's for serialized canvas.
  • in defer-uploads, we might end up serializing same dom twice, after resizing it.
  • hence, in current implementation below is the flow of events -
    • resize page to 1200 and seriaze dom and generate data-percy-element-id for canvas as - abcd
    • resize dom to 500px, and trigger seriaize dom again.
    • since canvas attribute already has data-percy-element-id therefore, we do not assign a new one.
    • hence, we serialize the canvas to image at 500px, and use the same url - abcd for this
    • hence, we captured canvas at 1200px and 500px, and both the times we named it the exact same value of abcd which was derived from data-percy-element-id which we have not updated when seriazing 500px dome.

related pr's-

@nilshah98 nilshah98 requested a review from a team as a code owner December 1, 2023 07:09
Copy link
Contributor

@ninadbstack ninadbstack left a comment

Choose a reason for hiding this comment

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

LGTM

cache[platform].$ = parseDOM(serializeDOM(), platform);
// save DOM, only after serializing it
// clone DOM, so that during next platform iteration, serializeDOM doesn't change current original DOM
cache[platform].dom = platform === 'shadow' ? dom : dom.cloneNode(true);
Copy link
Contributor

@itsjwala itsjwala Dec 4, 2023

Choose a reason for hiding this comment

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

why are we cloning DOM here?

because our assertions are againts original DOM, if we clone it we're not checking against original DOM when APIs change in future and there is drift between cloned DOM and original DOM.

Copy link
Contributor

Choose a reason for hiding this comment

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

serializeDOM() already does that for us.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Here is the test preparation workflow that is happening for Chrome -

  1. We create plain DOM, and then run serialzeDOM on it, and store this in cache['plain']
  2. Then we take the same DOM attach shadow components to it, and then run serializeDOM on it again, and store this in cache['shadow']
  3. So here, the plain DOM part is getting serialized twice, and since while storing in cache['plain'] we store by reference, it get's updated to be the newly serialized plain DOM, whereas the serializedDOM from first iteration is intact.

Copy link
Contributor

Choose a reason for hiding this comment

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

understood, in this case we shouldn't be calling dom.cloneNode rather our custom clone node traversal code, will update and merge.

This comment was marked as outdated.

@github-actions github-actions bot added the 🍞 stale Closed due to inactivity label Dec 19, 2023
@itsjwala itsjwala added 🐛 bug Something isn't working and removed 🍞 stale Closed due to inactivity labels Dec 22, 2023
Copy link

github-actions bot commented Jan 9, 2024

This PR is stale because it has been open for more than 14 days with no activity. Remove stale label or comment or this will be closed in 14 days.

@github-actions github-actions bot added the 🍞 stale Closed due to inactivity label Jan 9, 2024
Copy link

This PR was closed because it has been stalled for 28 days with no activity.

@github-actions github-actions bot closed this Jan 30, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
🐛 bug Something isn't working 🍞 stale Closed due to inactivity
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants