ChromoteSession$screenshot() triggers a page resize before screenshot.
#96
Comments
|
@yogat3ch - tagging you here for the easy follow. |
|
I added |
|
A couple of ideas for addressing this:
Thanks |
Related rstudio/shinytest2#220
😃 |
Using comment from https://github.com/rstudio/shinytest2/issues/218#issuecomment-1146097081 that suggests to use "round" numbers for easier division. While this isn't a perfect fix, it provides a much better opportunity to succeed at first run. If trouble still arises from rounded corners, then the `threshold` arg can be used.
|
So I can still reprex this issue with the latest of everything. Thank you for the reprex repo with The issue can be reproduced with a window that is larger than 992px wide and by calling For some really weird reason, Chrome DevTools makes jQuery believe the window size has changed, causing This calls: https://github.com/ColorlibHQ/AdminLTE/blob/75deb497b39c1a8547fe0f21a2478b066b223396/build/js/PushMenu.js#L107-L125 ... which believes the window width is Work around: If the AdminLTE3 can disable the auto collapse by setting the push menu option This is not a fix, but there is no longer any I don't know of a permanent fix as there is nothing that we are doing. I'd like to point the finger at the Chrome DevTools. @yogat3ch, please let me know if this |
|
If the option can't be set, AdminLTE3 could be patched and have the resize method be debounced or throttled. This would avoid the really really small time domain where the window believes it has a width of 1px and a height of 1px. |
|
Small reprex app to get the resize to show up: app <-
shinytest2::AppDriver$new(
shiny::shinyApp(
ui = shiny::fluidPage(
shiny::tags$h1("Does it resize?", style="height:400px;width:400px;background-color:lightblue;"),
shiny::tags$script("
$(function() {
$(window).resize(function(){
console.log('resize triggered! Current window size: ', $(window).height(), 'x', $(window).width())
})
})
")
),
server = function(...) {}
)
)
# app$view()
app$get_screenshot() # Ignoring result
app$get_logs()
#> .... (Previous logs removed for brevity)
#> {chromote} JS info 09:18:03.45 shinytest2; Shiny has been idle for 200ms
#> {shinytest2} R info 09:18:03.45 Shiny app started
#> {shinytest2} R info 09:18:03.78 Viewing chromote session
#> {shinytest2} R info 09:18:11.92 Taking screenshot
{chromote} JS log 10:14:30.34 resize triggered! Current window size: 1 x 1
(anonymous) @ :22:22
dispatch @ jquery-3.6.0/jquery.min.js:1:43063
v.handle @ jquery-3.6.0/jquery.min.js:1:41047
{chromote} JS log 10:14:30.35 resize triggered! Current window size: 1323 x 992
(anonymous) @ :22:22
dispatch @ jquery-3.6.0/jquery.min.js:1:43063
v.handle @ jquery-3.6.0/jquery.min.js:1:41047
{shiny} R stderr ----------- Loading required package: shiny
{shiny} R stderr ----------- Running application in test mode.
{shiny} R stderr -----------
{shiny} R stderr ----------- Listening on http://127.0.0.1:7415
^^ That's an issue since we do not believe **Investigating |
|
Moving this issue as it is an underlying issue in |
|
Displaying the commands with a list(
method = "Page.captureScreenshot",
params = list(
clip = list(
x = 0, y = 0,
width = 992, height = 430,
scale = 1
),
fromSurface = TRUE,
captureBeyondViewport = TRUE
)
)Before the above command, no resize is triggered. After the command, two resizes are triggered: (HxW) 1x1, then the viewport size of 1323x992. Logs when
|
|
Link to repo that explores this bug in Chrome DevTools Protocol: https://github.com/schloerke/chrome-devtools-protocol-screenshot-bug Link to bug filed with Chromium: https://bugs.chromium.org/p/chromium/issues/detail?id=1414460 |
|
@wch I can repro this unexpected behavior with chrome devtools protocol, not just Should we revert #83? Or adopt a approach similar to https://github.com/puppeteer/puppeteer/blob/abcc1756dd434dbe27d322aa9692b7fd9858a9ca/packages/puppeteer-core/src/common/Page.ts#L1400-L1419 ? I believe the only clean solution is that Chrome DevTools fixes itself and we maintain our current code. |
|
Can we rename this issue? Something like: I'm currently having to do a lot of gymnastics to avoid the consequences of the page refresh. I think we should consider one of these options for updating the screenshot method:
|
hadley
changed the title
ChromoteSession$screenshot() triggers a page resize before screenshot.
|
I'd suggest we take the puppeteer approach. |
Hi there!
Was working through building out some new testing frameworks on some of our apps and ran into some trouble developing simple snapshots. We're currently using bs4Dash for a lot of our app layouts, and it looks like there may be some compatibility issues with the snapshotting features with using this layout. Wondering if anyone has had these same issues and if it might be possible to diagnose.
I've developed a small reprex to illustrate the issue, which can be viewed (and forked) here.
In short, it appears as though there are small differences in the margins/re-sizing of elements when snapshots are taken that are generating differences between the reference images and the new snapshots. We've tried a few workarounds using
Sys.sleep()to determine if it might be an animation wait-time issue, with little success. Any help anyone could provide would be great - thank you!The text was updated successfully, but these errors were encountered: