Closed zleight1 closed 4 years ago
Would like to add to this here as well @timhaines . We started noticing a number of false positives coming up on our end where we are doing height detection of elements and for some reason seeing some variability on what heights are being set in the snapshots: https://percy.io/538fc19a/IBM.com-Library-React/builds/6330016
@Robdel12 I see you're the most recent active here, any chance this could be handled? I'd be happy to contribute if you can give me a bit of guidance to where this would best be implemented in the code.
Hey @zleight1! Unfortunately this isn't something that can be implemented in the SDKs -- this would need to be changed in Percy's rendering infrastructure.
Do you have any suggestions on how to address this?
It seems like a few people ran into this issue. I did find in an issue thread for the base client api that the default is 2 seconds from DOM content loaded, would it be possible to just expose that as a rest API option that the client calls?
On Mon, 14 Sep 2020 at 18:20 Robert DeLuca notifications@github.com wrote:
Hey @zleight1 https://github.com/zleight1! Unfortunately this isn't something that can be implemented in the SDKs -- this would need to be changed in Percy's rendering infrastructure.
— You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/percy/percy-storybook/issues/220#issuecomment-692128554, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACEJBWISVYFFXVVFQOVILRTSFYYFBANCNFSM4PFO6RZQ .
The short answer would be to check is being rendered within that story & what might cause it to render slowly. The next option would be to use a different SDK to capture the stories so you can control capturing them at the right time/state.
A lot has changed since that issue. Percy's infrastructure has a few steps it takes before capturing a screenshot:
load
event to fire The Storybook SDK differs from all of our SDKs in a major way -- it's building all of the DOM within our browsers at render time (rather than rerendering fully formed DOM). This sort of turns our infra into functional test suite (and it's hard to know when this arbitrary component is 'done' loading).
Fair enough. I guess any complex rendering cases we could handle as a one-off with the puppeteer SDK as you suggested.
Might be worthwhile to close/update any of the threads I referenced with your updated info.
Thanks for the help!
On Mon, Sep 14, 2020 at 7:06 PM Robert DeLuca notifications@github.com wrote:
The short answer would be to check is being rendered within that story & what might cause it to render slowly. The next option would be to use a different SDK to capture the stories so you can control capturing them at the right time/state.
A lot has changed since that issue. Percy's infrastructure has a few steps it takes before capturing a screenshot:
- Wait for the browser load event to fire
- Wait for all current in-flight network requests to resolve
- Wait for any currently loading fonts to resolve (using the fonts API)
- Wait a hard coded, non-configurable 3 seconds
- 📸 Screenshot time
The Storybook SDK differs from all of our SDKs in a major way -- it's building all of the DOM within our browsers at render time (rather than rerendering fully formed DOM). This sort of turns our infra into functional test suite (and it's hard to know when this arbitrary component is 'done' loading).
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/percy/percy-storybook/issues/220#issuecomment-692156264, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACEJBWM4PKR2E3K32OTUI73SFY5PFANCNFSM4PFO6RZQ .
We have some stories that have various things like pop-ups, drop-downs, etc., some of which need a few hundred milliseconds to display properly. Otherwise we end up with a lot of false differences that aren't "stable" between test runs.
Chromatic has a feature where you can delay all stories in a file, or individual stories before taking the screenshot in order to account for situations like this. Chromatic delay
Is this something that exists already (if so maybe I missed it in the docs 😨)?
If it doesn't exist, is it something that would prevent it from being implemented?
It seems pretty straightforward, so I will try and see if I can implement it and send a PR.
Thanks!