1819984 - Screenshot fails for specific tweet with `screenshots.browser.component.enabled`

Status: RESOLVED DUPLICATE of bug 1818862

(Firefox :: Screenshots, defect)

Description

[Chris Peterson [:cpeterson]]

Steps to reproduce

1. Set screenshots.browser.component.enabled pref = true.
2. Load https://twitter.com/Scriffey/status/1493389985579417603
3. Try to "Take Screenshot" of the page or an element on the page and "Download".

Expected result

The screenshot should be saved to a file.

Actual result

The screenshot download appears in the downloads menu, but stops with a "Failed" message.

I can reproduce this bug in a clean profile in old builds from 2022, so this is not an add-on problem or a recent regression. I'm testing on Windows 11.

The problem seems to be specific to that tweet https://twitter.com/Scriffey/status/1493389985579417603. If I click to focus any reply tweets or other tweets, I can successfully take and download screenshots of those tweets.

Comment 1

[Sam Foster [:sfoster] (he/him)]

(In reply to Chris Peterson [:cpeterson] from comment #0)

The problem seems to be specific to that tweet https://twitter.com/Scriffey/status/1493389985579417603. If I click to focus any reply tweets or other tweets, I can successfully take and download screenshots of those tweets.

I'm not able to reproduce this on Ubuntu, new profile and not logged in to Twitter. So I'm not sure which of those variables is significant. I guess twitter could deliver different content to different platforms? But if we were able to render it, we should also be able to screenshot it. Is there any more details in the console or stdout :cpeterson?

Comment 2

[Chris Peterson [:cpeterson]]

(In reply to Sam Foster [:sfoster] (he/him) from comment #1)

I'm not able to reproduce this on Ubuntu, new profile and not logged in to Twitter. So I'm not sure which of those variables is significant. I guess twitter could deliver different content to different platforms? But if we were able to render it, we should also be able to screenshot it.

I can copy the screenshot (and paste it into another app), so the screenshot is being rendered. So the problem seems to be when saving the file.

Is there any more details in the console or stdout :cpeterson?

I don't see any relevant warnings or errors in the browser or web console. Are there any about:logging flags I can enable?

I tested on my Mac and I wasn't able to reproduce the problem. So this is something specific to Windows or my Windows machine.

Comment 3

[Sam Foster [:sfoster] (he/him)]

(In reply to Chris Peterson [:cpeterson] from comment #2)

I can copy the screenshot (and paste it into another app), so the screenshot is being rendered. So the problem seems to be when saving the file.

Ah ha! This starts to sound like bug 1818862. The length of the document title is 228 chars, and if your download directory was "C:/Users/longishusername/Downloads", we just exceeded max pathname length on Windows (MAX_PATH), which would result in a failure to download the file. If that sounds right, I can dupe it. Any details you can add there would be appreciated, but broadly the plan is to build the whole pathname before truncating it to the max length where we can know the download directory path, and truncate back to a very conservative length when that is unknown.

Comment 4

[Chris Peterson [:cpeterson]]

Yes! I think my bug is the same problem. When I was able to successful save the screenshot file on macOS, I did notice that the filename was very long.

I'll dupe my bug to bug 1818862.