Screenshot file naming is now broken

[Picard12]

Hi, Screenshot file naming in Firefox is now broken for me. The lack of exact timestamp (hour, minute, second) makes taking several scrrenshots of the same page a hurdle and requires manual change of the name in order not to overwrite the previous file.

Current naming scheme: Screenshot 2024-06-20 a[...].png

Previous naming scheme: Screenshot 2023-08-14 at 04-04-22 Glowna _ X.png

Please bring back the old one with the exact timestamp.

Thanks,

Mikolaj

[Agentvirtuel]

Hello

For information purposes, taking screenshots
https://firefox-source-docs.mozilla.org/devtools-user/taking_screenshots/index.html

https://www.youtube.com/embed/XE1MpIMi594
https://www.youtube.com/embed/optjk7BPOu0

[sfoster]

I think we are talking about the built-in browser Screenshots feature here, not the functionality in devtools. So, the best support page is https://support.mozilla.org/kb/take-screenshots-firefox.

[Agentvirtuel]

Hello

Of course, Mozilla Connect is a collective space where we can share comments and ideas.

[jscher2000]

The file names had to be shortened to work around a problem with overly long names being unsave-able. For example, when I go to save a screenshot of this page:

Screenshot 2024-06-20 at 13-22-25 Screenshot file namin[...].png

(That's a total of 65 characters, which seems unnecessarily short.)

I don't know why the [...] comes so soon on yours. Are you are saving the file in a deeply nested folder? I wonder whether the entire path to the file is taken into account when shortening the name.

[sfoster]

We had a number of reports like this, which ended up being tracked and ultimately fixed by bug 1902341. That fix should be in our current release version of Firefox, so I'm curious to know if anyone is still running into the problem after they updated.  

[glenndh]

Yes, the problem does still exist. I have reverted to 126.0 to allow screenshot downloads with full filenames. I never had any problems with long filenames prior to 127.0  Glenn

[RS55]

I'm here because the problem keeps happening. Just now, I got only 28 characters & spaces before the file name was cut off: Screenshot 2024-07-02 a[...]

I'm saving directly to the Downloads folder on a fairly new laptop. I keep hoping this is fixed with each new update. I have no issue saving long file names otherwise.

[sfoster]

To be clear, the issue described here is a bug, not an intentional change in how we create those filenames. We did need to fix a few things here to ensure the filename is saveable on all the platforms, and it is possible we over-corrected and need to do more work here still.

[lwolf]

can you please restore the old behavior without ANY paternalism?

I'm 99,9% sure that everyone who's using this feature is able to realize and cut long filenames

plus

I'm 99,9% sure that everyone who's using this feature is NOW upset with filenames like Screenshot 2024-07-02 a[...].png and it will NOT be better with 30, 40 or 60 characters!!!!!

Just stop wasting time (yours and ours!)

thanks in advance

[glenndh]

cor-el

• Moderator
• Top 10 Contributor

7/2/24, 12:14 PM

more options

Chosen Solution

You can set screenshots.browser.component.enabled to false in about:config to revert to the old behavior.

This is a reply to the same problem on a different post.

Helpful?

Yes 2 👍 

[lwolf]

Thanks for the response. But actually this does not revert exactly to the old behavior. The naming is like before but

1. when i select "save full page" then the preview already seems to have twice the width and height and

2. it doesn't matter whether i use "save full page" or just select something, then loading produces always a picture that has twice the width and height.

And this changed only with that recommended about:config line because

1. loading screenshots with shortened filename (made before about:config change) don't show this behavior.

2. loading old screenshots (made before this "feature" was introduced) don't show this behavior.

[RS55]

---

@glenndh wrote:

cor-el

• Moderator
• Top 10 Contributor

7/2/24, 12:14 PM

more options

Chosen Solution

You can set screenshots.browser.component.enabled to false in about:config to revert to the old behavior.

This is a reply to the same problem on a different post.

---

This worked for me as far as I can tell, in regards to getting back the timestamp and site name. Thank you for posting this!

[aLDimeTech]

---

@glenndh wrote:

cor-el

• Moderator
• Top 10 Contributor

7/2/24, 12:14 PM

more options

Chosen Solution

You can set screenshots.browser.component.enabled to false in about:config to revert to the old behavior.

Great, grateful a lot! I'm happy again 😉

[lwolf]

update: the additional added space seems to depend on a mysterious way to the font size. The smaller the font size is, the bigger is the margin. And it is not like a constant size, e.g. a theoretical value that just depends on the content. For example with normal size, the resulting screenshot has a width of 2880 pixel. While with a small font size (expecting either a) a smaller size when zoom is reproduced in screenshot or b) same size when zoom is just a different visualization), the resulting screenshot grows to a width of 5760 pixel. 😖

[lwolf]

With a zoom of 200% there are no margins. For pages with short paragraphs like here, it could be a solution. But on pages with a lot of text, the screenshots look terrible because the words per line is then just 50% and the height therefore 200%.🤕

[aLDimeTech]

Likewise. Why spoil something that worked well for years? Or is it, as usual, “not bug but feature”

[sfoster]

It wasn't working very well. The new implementation fixed dozens of bugs in Screenshots - there's a list of bugs resolved here. The zoom issues described here among them.