One of the challenges we are currently facing with dynamic (JS-based) changes to our page DOM, is that we don't really know exactly what kind of DOM state is frozen and uploaded to percy.io
Even the debug log does not provide this.
So we need a lot of trial-and-error playing around with timeout values, beforeSnapshot Javascripts hacks, etc.
Suggested new feature for percy snapshot command:
What would be really helpful in that case, would be a --dump directory option for the percy snapshot command.
This option should cause percy to write a copy of the frozen DOM tree as a file to that folder, also including all the assets it identified during asset discovery phase. In other words a full 1-1 as-is copy of everything that percy uploads to the cloud for the screenshots to be taken.
One of the challenges we are currently facing with dynamic (JS-based) changes to our page DOM, is that we don't really know exactly what kind of DOM state is frozen and uploaded to percy.io
Even the debug log does not provide this.
So we need a lot of trial-and-error playing around with timeout values, beforeSnapshot Javascripts hacks, etc.
Suggested new feature for percy snapshot command:
What would be really helpful in that case, would be a --dump directory option for the percy snapshot command.
This option should cause percy to write a copy of the frozen DOM tree as a file to that folder, also including all the assets it identified during asset discovery phase. In other words a full 1-1 as-is copy of everything that percy uploads to the cloud for the screenshots to be taken.