User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.108 Safari/537.36

Steps to reproduce:

I used the geckodriver screenshot command to take a screenshot of the current viewport, so parameter full=false, but it crashes if I scroll the page to particular location and then take the screenshot. This crashes every time tried. Also Firefox itself closes killing the session which is unfortunate.

Geckodriver version: v0.26.0
Firefox version: 70.0.1 (64-bit) Windows

1. Navigate to: https://www.blueorigin.com/latest/gallery
2. Scroll page to Y: 2330
3. Take screenshot with full=false
4. See crash

Hope this helps, happy to provide more information.

Actual results:

1574450644817 webdriver::server DEBUG -> POST /session/41e5b0a8-c55e-4234-a58b-4f3832fde7ed/execute/sync {"args":[],"script":"window.scrollTo(0, 2330);"}
1574450644821 webdriver::server DEBUG <- 200 OK {"value":null}
1574450644822 webdriver::server DEBUG -> GET /session/41e5b0a8-c55e-4234-a58b-4f3832fde7ed/screenshot
1574450645644 webdriver::server DEBUG <- 500 Internal Server Error {"value":{"error":"unknown error","message":"[Exception... "Data conversion failed because significant data would be lost" nsresult: "0x80460003 (NS_ERROR_LOSS_OF_SIGNIFICANT_DATA)" location: "JS frame :: resource://gre/modules/AsyncShutdown.jsm :: observe :: line 551" data: no]","stacktrace":"observe@resource://gre/modules/AsyncShutdown.jsm:551:16\nobserve@resource:///modules/ContentCrashHandlers.jsm:177:28\n"}}

Expected results:

It should have taken a screenshot and not have crashed. The bummer here is it actually closes Firefox killing the session as well. This is not ideal. I would expect some sort of a response error code that could be recovered from.

One thing to note, this appears to trigger when I try to screenshot the viewport near the bottom of the page. Not sure if that's why this fails, but it's how I reproduce it. The Y location above is where I get it to fail everytime on my box with a screen resolution of: 1080x1920.

As discovered on bug 1590933 this could happen if the page hasn't been fully loaded yet. How does your full code looks like for this particular case? Are you waiting for a complete page load? The short trace log doesn't actually show this problem.

Ok, I can see the same when trying to do a full screenshot with the above mentioned website and a small modification to Marionette:

diff --git a/testing/marionette/listener.js b/testing/marionette/listener.js
--- a/testing/marionette/listener.js
+++ b/testing/marionette/listener.js
@@ -1663,8 +1663,8 @@ function getScreenshotRect({ el, full =
     }
     rect = getElementRect(el);
   } else if (full) {
-    let clientRect = win.document.documentElement.getBoundingClientRect();
-    rect = new DOMRect(0, 0, clientRect.width, clientRect.height);
+    const body = win.document.body;
+    rect = new DOMRect(0, 0, body.width, body.height);
   } else {
     // viewport
     rect = new DOMRect(

As it looks like this is graphics related. It's also a very huge amount of data to transfer internally via IPC. I assume that there is something broken.

Note that WebDriver/Marionette supports different page loading
strategies, not all of which wait for the document navigation to
mature (document.readyState to reach complete). So it should
be possible to take a screenshot without the browser crashing under
those conditions as well.

Note that this isn't a problem related to loading the page and not waiting for. It actually seems to be a bug in the drawSnapshot() API. I will have more data soon.

I caught this crash in the debugger, and based on the stack trace this crash is already known and covered by bug 1595395. For now I will mark it dependent on that other bug.

(In reply to Henrik Skupin (:whimboo) [⌚️UTC+2] from comment #3)

Ok, I can see the same when trying to do a full screenshot with the above mentioned website and a small modification to Marionette:

diff --git a/testing/marionette/listener.js b/testing/marionette/listener.js
--- a/testing/marionette/listener.js
+++ b/testing/marionette/listener.js
@@ -1663,8 +1663,8 @@ function getScreenshotRect({ el, full =
     }
     rect = getElementRect(el);
   } else if (full) {
-    let clientRect = win.document.documentElement.getBoundingClientRect();
-    rect = new DOMRect(0, 0, clientRect.width, clientRect.height);
+    const body = win.document.body;
+    rect = new DOMRect(0, 0, body.width, body.height);
   } else {
     // viewport
     rect = new DOMRect(

As it looks like this is graphics related. It's also a very huge amount of data to transfer internally via IPC. I assume that there is something broken.

Henrik,

Thank you for taking the time to look into this bug.

It is a large amount of data, but it's the same amount of data transferred if you were to take a viewport screenshot right? The screenshot Marionette command I used above to trigger this had full=false so it should have only had to transfer pixel data for the viewport dimensions.

Great point about the page being loaded, all my tests conducted were with the page being full loaded, I even waited 1 minute after the page was loaded to ensure it's not related to that. My apologies for not specifying that above.

Thanks.

(In reply to matt from comment #7)

It is a large amount of data, but it's the same amount of data transferred if you were to take a viewport screenshot right? The screenshot Marionette command I used above to trigger this had full=false so it should have only had to transfer pixel data for the viewport dimensions.

For a full screenshot it will be most of the time a larger chunk of data. PNG doesn't have compression, but only benefits when there is the exact same color in large areas across the to capture rect. In your URL this isn't the case. So depending on your screen size and if Firefox runs maximized, you can even hit this problem with a viewport capture only. Also on machines with high-res displays the pixel ratio is larger than 1, which means the image is 4x that large.

(In reply to Henrik Skupin (:whimboo) [⌚️UTC+2] from comment #8)

(In reply to matt from comment #7)

It is a large amount of data, but it's the same amount of data transferred if you were to take a viewport screenshot right? The screenshot Marionette command I used above to trigger this had full=false so it should have only had to transfer pixel data for the viewport dimensions.

For a full screenshot it will be most of the time a larger chunk of data. PNG doesn't have compression, but only benefits when there is the exact same color in large areas across the to capture rect. In your URL this isn't the case. So depending on your screen size and if Firefox runs maximized, you can even hit this problem with a viewport capture only. Also on machines with high-res displays the pixel ratio is larger than 1, which means the image is 4x that large.

That makes sense. I have a test box with a small screen resolution that still causes this crash. Would you like me to send you the viewport dimensions when maximized? My thinking is if it's a smaller amount of data being transferred but still causing a crash maybe this issue isn't data size dependent? Just a thought.

Thank you for explaining that further above!

I would suggest that you follow bug 1595395, which is the place where a fix is necessary. We cannot do anything for Marionette right now. :/

As workaround you would have to use Firefox 69 for now, which doesn't have this problem because it doesn't depend on this new API.

(In reply to Henrik Skupin (:whimboo) [⌚️UTC+2] from comment #10)

I would suggest that you follow bug 1595395, which is the place where a fix is necessary. We cannot do anything for Marionette right now. :/

As workaround you would have to use Firefox 69 for now, which doesn't have this problem because it doesn't depend on this new API.

Great to know about being able to use Firefox 69 as a workaround, I didn't know that so thank you.

I'll follow that bug, thank you for sharing that link. If you don't mind me asking, why can't Marionette be worked on? Just curious! I love to follow your guys development when I can.

Thanks for your hard work. Really appreciate it.

The crash here doesn't happen in Marionette but in the IPC sub system of Firefox. And I would like to see that fixed first before doing any work on better support of full page screenshots.

Is there any fix upcoming for this bug? I'm using python Selenium and trying to take full page screenshot when browsing a YouTube page ends up in this error.

• OS: Windows x86_64
• Firefox affected versions: 69/70/71/72 beta

Very simple example

# Selenium 4.0.0a3 is the first release to officially support full page screenshot endpoint
# (pip install selenium==4.0.0a3)
from selenium.webdriver import Firefox, DesiredCapabilities, FirefoxProfile
from selenium.webdriver.firefox.options import Options

profile = FirefoxProfile()
# Allow autoplay
profile.set_preference("media.autoplay.default", 0)
cap = DesiredCapabilities.FIREFOX
options = Options()
webdriver = Firefox(firefox_profile=profile, capabilities=cap, options=options)
webdriver.get("https://www.youtube.com/watch?v=EzKkl64rRbM")
webdriver.save_screenshot("viewport.png")
webdriver.get_full_page_screenshot_as_file("full_page.png")

Thanks in advance

May I add that using GCLI commnad

:screenshot --fullpage

exports screenshot perfectly (1349 x 2403 using 1366 x 768 window size) but I can't use GCLI commands from WebDriver

Matt or Picci, can one of you please test the latest Firefox Nightly build? You can download it from https://www.mozilla.org/en-US/firefox/channel/desktop/#nightly. Does the problem still exist for you after bug 1600124 has been fixed now?

Using latest nightly ( 73.0a1 (2019-12-17) (64-bit) ) now I get a different error

selenium.common.exceptions.WebDriverException: Message: [Exception... "Failure"  nsresult: "0x80004005 (NS_ERROR_FAILURE)"  location: "JS frame :: chrome://marionette/content/capture.js ::
capture.canvas :: line 140"  data: no]
Stacktrace:
capture.canvas@chrome://marionette/content/capture.js:140:62
GeckoDriver.prototype.takeScreenshot@chrome://marionette/content/driver.js:3032:30
Async*despatch@chrome://marionette/content/server.js:305:40
execute@chrome://marionette/content/server.js:275:16
onPacket/<@chrome://marionette/content/server.js:248:20
onPacket@chrome://marionette/content/server.js:249:9
_onJSONObjectReady/<@chrome://marionette/content/transport.js:501:20

If you need any other kind of trace or log, just point me in the direction of how to get it. I will be glad to help on resolving this.

PS: Firefox is not closing after failing on taking the screenshot, it just sends this WebDriver Exception from marionette

Geckodriver logs do not add any info

1576599135591   geckodriver::capabilities       DEBUG   Trying to read firefox version from ini files
1576599135592   geckodriver::capabilities       DEBUG   Found version 73.0a1
1576599135593   geckodriver::capabilities       DEBUG   Extracting profile to C:\Users\picch\AppData\Local\Temp\rust_mozprofilezNrR35\user.js
1576599135624   mozrunner::runner       INFO    Running command: "C:\\Program Files\\Firefox Nightly\\firefox.exe" "-marionette" "-foreground" "-no-remote" "-profile" "C:\\Users\\picch\\AppData\\Local\\Temp\\rust_mozprofilezNrR35"
1576599135631   geckodriver::marionette DEBUG   Waiting 60s to connect to browser on 127.0.0.1:63839
1576599140364   geckodriver::marionette DEBUG   Connection to Marionette established on 127.0.0.1:63839.
1576599140455   webdriver::server       DEBUG   <- 200 OK {"value":{"sessionId":"eab3ea99-5826-4edc-a38d-2cc3349fad10","capabilities":{"acceptInsecureCerts":true,"browserName":"firefox","browserVersion":"73.0a1","moz:accessibilityChecks":false,"moz:buildID":"20191217104440","moz:geckodriverVersion":"0.26.0","moz:headless":false,"moz:processID":14256,"moz:profile":"C:\\Users\\picch\\AppData\\Local\\Temp\\rust_mozprofilezNrR35","moz:shutdownTimeout":60000,"moz:useNonSpecCompliantPointerOrigin":false,"moz:webdriverClick":true,"pageLoadStrategy":"normal","platformName":"windows","platformVersion":"10.0","rotatable":false,"setWindowRect":true,"strictFileInteractability":false,"timeouts":{"implicit":0,"pageLoad":300000,"script":30000},"unhandledPromptBehavior":"dismiss and notify"}}}
1576599140464   webdriver::server       DEBUG   -> POST /session/eab3ea99-5826-4edc-a38d-2cc3349fad10/url {"url": "https://www.youtube.com/watch?v=EzKkl64rRbM"}
1576599156434   webdriver::server       DEBUG   <- 200 OK {"value":null}
1576599159442   webdriver::server       DEBUG   -> GET /session/eab3ea99-5826-4edc-a38d-2cc3349fad10/moz/screenshot/full
1576599159453   webdriver::server       DEBUG   <- 500 Internal Server Error {"value":{"error":"unknown error","message":"[Exception... \"Failure\"  nsresult: \"0x80004005 (NS_ERROR_FAILURE)\"  location: \"JS frame :: chrome://marionette/content/capture.js :: capture.canvas :: line 140\"  data: no]","stacktrace":"capture.canvas@chrome://marionette/content/capture.js:140:62\nGeckoDriver.prototype.takeScreenshot@chrome://marionette/content/driver.js:3032:30\nAsync*despatch@chrome://marionette/content/server.js:305:40\nexecute@chrome://marionette/content/server.js:275:16\nonPacket/<@chrome://marionette/content/server.js:248:20\nonPacket@chrome://marionette/content/server.js:249:9\n_onJSONObjectReady/<@chrome://marionette/content/transport.js:501:20\n"}}

(In reply to Henrik Skupin (:whimboo) [⌚️UTC+1] from comment #15)

Matt or Picci, can one of you please test the latest Firefox Nightly build? You can download it from https://www.mozilla.org/en-US/firefox/channel/desktop/#nightly. Does the problem still exist for you after bug 1600124 has been fixed now?

Henrik,

I ran a test using the nightly version: 73.0a1, and I didn't get any errors or crashes on the BlueOrigin page I originally found this issue on above: https://www.blueorigin.com/latest/gallery

I did not run into the issues that picchi.lucas specified above.

Looks good on this end!

Thanks.

Great to hear that Matt! Looks like that the fix from bug 1595395 made it work for you. I'm going to close this bug as fixed.

Also Picchi, please file your issue as a new bug. Thanks.

All right already filled a new bug. Thanks!

In case it's helpful, I get the same error when taking a fullscreen screenshot of this page: https://theodi.org/events

Replicated on Firefox 71.0, geckodriver 0.26.0, Ubuntu 18.04

Bugbug thinks this bug is a regression, but please revert this change in case of error.