Closed Bug 1902715 Opened 3 months ago Closed 1 month ago

The default screenshot tool now cuts off the file name after the date almost every time. Thus, the capture time no longer appears and poses a problem when saving file if several captures are made in the same day.

Categories

(Firefox :: Screenshots, defect)

Product:
Firefox
Component:
Screenshots
Version:
Firefox 127
Type:
defect

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: ju_3j, Unassigned)

References

Details

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:127.0) Gecko/20100101 Firefox/127.0

Steps to reproduce:

Use the default screenshot tool.

Actual results:

As of a few days ago, the default screenshot tool now cuts off the file name after the date almost every time. Thus, the capture time no longer appears and poses a problem when saving the file if two, three or more captures are made in the same day, because these screenshot files have the same name.

Expected results:

Could we revert to the previous version, or cut after the hour-minute-second of the default file name? Thanks in advance for this correction.

The Bugbug bot thinks this bug should belong to the 'Firefox::Screenshots' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Component: Untriaged → Screenshots

(In reply to Julien from comment #0)

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:127.0) Gecko/20100101 Firefox/127.0

Steps to reproduce:
Use the default screenshot tool.

Can you provide some examples of pages where this happens?

Could we revert to the previous version, or cut after the hour-minute-second of the default file name? Thanks in advance for this correction.

We will try and get this fixed. If you want to revert temporarily you can set screenshots.browser.component.enabled to false in about:config. The old implementation will go away in a few versions once we've got all these kinks worked out.

Flags: needinfo?(ju_3j)
Duplicate of this bug: 1902710

Hi, I have the same issue, and I've just noticed it's not reproduce-able on any page, but it is always occurring on a page where the title contains ':', and also other "non-ascii" characters, for example:

<head>
	<title>Vœux : réponses des formations - Parcoursup</title>
	<meta http-equiv="Content-Type" content="text/html; charset=utf8"/>

(The URL is https://dossier.parcoursup.fr/Candidat/admissions?ACTION=0 but you need to login to get access and can't just create an account, it's a french government website for students).

The suggested screenshot name is then Screenshot 2024-06-18 a[...].png ... Screenshots was working well with the same website untile 2024-06-13, I have a screenshot named Screenshot 2024-06-12 at 18-10-54 Vœux réponses des formations - Parcoursup.png. I can't tell if the ':' was added on this website then or if I've updated to Firefox 127 at this point (it seems I've updated on 2024-06-13 though)

Julien, I'm curious to know if bug 1902341 fixed this issue for you? Bug 1902341 just landed in Nightly.

I'm not Julien but it does fix it for me 👍 (although my profile won't load when I go back to the regular build)

I'm not able to reproduce this. With the title "Vœux : réponses des formations - Parcoursup" I get a screenshot filename of Screenshot 2024-06-20 at 12-26-59 Vœux réponses des formations - Parcoursup.png which is what I would expect. If anyone has more detailed steps to reproduce, I'd love to better understand what is going on here so we can land a fix.

I could reproduce this.
I hope this info helps you.

URL: https://wikiwiki.jp/kancolle/
<title>艦隊これくしょん -艦これ- 攻略 Wiki*</title>
file name: Screenshot 2024-06-21 a[...].png

URL: https://www.yahoo.co.jp/
<title>Yahoo! JAPAN</title>
file name: Screenshot 2024-06-21 at 09-52-53 Yahoo! JAPAN.png

URL: https://x.com/home
#no <title> tag in HTML source.
file name: Screenshot 2024-06-21 at 09-53-44 ホーム _ X.png

I'm able to reproduce with the following web document:

 <!DOCTYPE html>
<html>
<head>
<title>ààààààààààà</title>
</head>
<body>

<h1>Title test</h1>
<p>Firefox screenshots</p>

</body>
</html>

Steps to reproduce:

  1. Load the page
  2. Right click anywhere, click on "Take Screenshot"
  3. Click on Save Full Page
  4. Click on Download

Results:

  • With àààààààààà as <title>, the screenshot file name is as expected: Screenshot 2024-06-21 at 08-48-57 àààààààààà.png
  • With ààààààààààà as <title>, the screenshot file name is too short: Screenshot 2024-06-21 a[...].png
  • With aaaaaaaaaaaaaaaaaaaa as <title>, the screenshot file name is as expected: Screenshot 2024-06-21 at 08-51-02 aaaaaaaaaaaaaaaaaaaa.png

Some of my environment details:

Name: Firefox
Version: 127.0.1
Build ID: 20240618110440
Distribution ID:
Update Channel: release
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:127.0) Gecko/20100101 Firefox/127.0
OS: Darwin 23.5.0 Darwin Kernel Version 23.5.0: Wed May 1 20:17:33 PDT 2024; root:xnu-10063.121.3~5/RELEASE_ARM64_T6031

Name: Firefox Screenshots
Version: 39.0.1
ID: screenshots@mozilla.org

Application Settings
Default Locale: "en-US"
Operating System
System Locales: ["en-US"]

See this reddit thread for more details regarding this bug.
I have not been able to reproduce this yet.
I've tried reproducing on Windows and macOS but still unable to.

I'm going to close this as a duplicate to bug 1902341, because the issue is fixed in bug 1902341.
Please re-open this bug if you are able to reproduce with bug 1902341.

Status: UNCONFIRMED → RESOLVED
Closed: 3 months ago
Duplicate of bug: 1902341
Resolution: --- → DUPLICATE
Duplicate of this bug: 1904196

I bring an example of the day with this screenshot. For the official website about weather in France "MeteoFrance", the screenshot tool can't save the entire title for this screen. For the comparison, I look back also an old screenshot with the original file name saved. When the title was too long, the file name was cut at the end, and not before the time capture.

url page :
https://meteofrance.com/previsions-meteo-france/belfort/90000

file title saved :
Screenshot 2024-06-25 a[...]

old file title for example (what I would expect) :
Screenshot 2021-09-17 at 18-24-35 METEO BELFORT par Météo-France - Prévisions Météo gratuites pour aujourd’hui, demain et à[...]

Flags: needinfo?(ju_3j)

(In reply to Grey Orion from comment #8)

URL: https://wikiwiki.jp/kancolle/
<title>艦隊これくしょん -艦これ- 攻略 Wiki*</title>
file name: Screenshot 2024-06-21 a[...].png

I get Screenshot 2024-06-27 at 12-12-55 艦隊これくしょん -艦これ- 攻略 Wiki.png when I save the screenshots from this page, in Windows 10.

(In reply to glitchim from comment #9)

I'm able to reproduce with the following web document:

  • With ààààààààààà as <title>, the screenshot file name is too short: Screenshot 2024-06-21 a[...].png

I'm also not able to reproduce this. However, the logic here needs to examine the full pathname, not just the filename, so depending on where you are saving the file we might get different results. For example, on my windows machine, I end up with C:\Users\sfoster\Downloads\Screenshot 2024-06-27 at 12-18-49 àààààààààààààà.png.

Some of my environment details:
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:127.0) Gecko/20100101 Firefox/127.0

Interesting. On MacOS I believe we should need to truncate much less frequently so this is surprising.

Some of these reports seem to suggest an ongoing issue that isnt solved by bug 1902341 so I'm going to re-open this bug for a bit more investigation.

Status: RESOLVED → REOPENED
No longer duplicate of bug: 1902341
Ever confirmed: true
Resolution: DUPLICATE → ---

Ah, bug re-opened I can comment :)

From the Reddit thread posted earlier, I found something: I have browser.download.useDownloadDir set to False, so everytime I download a screenshot, I'm asked where I want to store it.

But when I set it to True (or untick "Always ask you where to save files" in the preferences) the issue disappears!

Maybe "you" try to calculate the file name size before knowing the actual path, or maybe with a strange MacOS contener-thingy value??

Oh no wait, it's worth, trying to screenshot this page we're on currently with direct download of the file, the download simply fails!?

*worse, sorry for the typo and the spam

(In reply to glitchim from comment #14)

From the Reddit thread posted earlier, I found something: I have browser.download.useDownloadDir set to False, so everytime I download a screenshot, I'm asked where I want to store it.

Can you share the path (or just the character length of the path) you chose to download the file to? The constraints are different between all the different platforms, so we may either have those wrong, or there's a logic error in how we apply them.

Maybe "you" try to calculate the file name size before knowing the actual path, or maybe with a strange MacOS contener-thingy value??

We do account for this, but it does get complicated when the download directory path is unknown until the prompt to pick where to save the file. At that point we can't go back and try again if the filename or pathname is invalid, so we have to fall back to a more conservative maximum filename length. Which is suspect is what is going on here and producing the unexpected results.

The implementation and logic that drives this is all in/around getFilename function.

Flags: needinfo?(7f6e09)

I'm testing again with a simple local html file.

With browser.download.useDownloadDir set to False:

with <title>ààààààààààà</title> the filename is truncated to Screenshot 2024-06-29 a[...].png before I choose the target directory.
The suggested directory is often the default one: /Users/bsod/Downloads so the whole path is /Users/bsod/Downloads/Screenshot 2024-06-29 a[...].png. With a 4 letters username that's pretty short ... But as you said, it's calculated before I pick a path.

with <title> 1902715 - The default screenshot tool now cuts off the file name after the date almost every time. Thus, the capture time no longer appears and poses a problem when saving file if several captures are made in the same day.</title>, the suggested filename is Screenshot 2024-06-29 at 00-32-38 1902715 - The default[...].png which is not so bad.

Now with browser.download.useDownloadDir set to True:

with <title>ààààààààààà</title> screenshot filename is not truncated (/Users/bsod/Downloads/Screenshot 2024-06-29 at 00-29-17 ààààààààààà.png)

with <title> 1902715 - The default screenshot tool now cuts off the file name after the date almost every time. Thus, the capture time no longer appears and poses a problem when saving file if several captures are made in the same day.</title> download simply fails!

Flags: needinfo?(7f6e09)

I have solved with browser.download.useDownloadDir = true.

URL: https://wikiwiki.jp/kancolle/

file name: Screenshot 2024-06-29 at 07-46-41 艦隊これくしょん -艦これ- 攻略 Wiki.png

If you are able to reproduce this issue, can you comment with the platform and what kind of filesystem you are attempting to save the file to? E.g. is it linux/ext4, windows 10 / NTFS, MacOS / HFS+ or AFS or some other? And if possible the full path to the directory - either your downloads directory or whatever directory you are picking when prompted.

Here is my platform.

Firefox 127.0.2 mint-001
Linux/ext4

directory path: /home/xxxxxxxxx/Downloads/

#xxxxxxxxx is 9 letters

(In reply to Grey Orion from comment #21)

Here is my platform.

Firefox 127.0.2 mint-001

We're pretty confident bug 1898027 will fix this issue for you. It will be in v128 which should reach you next week. You can test it today in Nightly or the current Beta version.

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

(In reply to Grey Orion from comment #21)

Here is my platform.

Firefox 127.0.2 mint-001

We're pretty confident bug 1898027 will fix this issue for you. It will be in v128 which should reach you next week. You can test it today in Nightly or the current Beta version.

Thank you Sam Foster.

I'll wait next stable release.

The severity field is not set for this bug.
:sfoster, could you have a look please?

For more information, please visit BugBot documentation.

Flags: needinfo?(sfoster)

With Firefox Version 128.0 Build ID 20240704121409 on macOS (Darwin 23.5.0), I cannot reproduce the issue anymore 👍👍👍

Installed version 128. Enabled screenshots.browser.component.enabled.
Now snapshots are saved in one folder.
In my opinion, it was more convenient before: each site had its own folder. Maybe you need to wait a little for the statistics to be collected.

(In reply to Yegor Yokarev from comment #26)

Installed version 128. Enabled screenshots.browser.component.enabled.

screenshots.browser.component.enabled is enabled by default in 128 so it shouldn't need to be enabled.

Now snapshots are saved in one folder.
In my opinion, it was more convenient before: each site had its own folder. Maybe you need to wait a little for the statistics to be collected.

We never saved screenshots where each site has its own folder.

If browser.download.useDownloadDir is true, we save to the default download directory.
If browser.download.useDownloadDir is false, the filepicker opens and you choose where the file is saved.

This behavior has not changed.

(In reply to Niklas Baumgardner [:niklas] from comment #27)

(In reply to Yegor Yokarev from comment #26)

Installed version 128. Enabled screenshots.browser.component.enabled.

screenshots.browser.component.enabled is enabled by default in 128 so it shouldn't need to be enabled.
after the problem appeared I turned off this option and used the "old version"

Now snapshots are saved in one folder.
In my opinion, it was more convenient before: each site had its own folder. Maybe you need to wait a little for the statistics to be collected.

We never saved screenshots where each site has its own folder.
This is probably an option of the Win 11 operating system, because it starts working after 1-2 weeks of constant use

If browser.download.useDownloadDir is true, we save to the default download directory.
If browser.download.useDownloadDir is false, the filepicker opens and you choose where the file is saved.
I always have browser.download.useDownloadDir` is false

This behavior has not changed.

Now that 128 is in release, I'm curious to know if anyone is still encountering this bug? There have been some discrepancies with the various reports but we've still been unable to reproduce with the patches from bug 1898027 and bug 1902341. If you are still running into this issue, please provide:

  • Operating system
  • Disk format if known (NTFS, ext4 etc.)
  • Is browser.download.useDownloadDir enabled?
  • The URL or title of the page you were trying to screenshot
  • The resulting filename and pathname if possible.
Flags: needinfo?(sfoster)

Should be fixed by this in 129.

Going to close this now as this is fixed by bug 1898027 and bug 1902341.

Status: REOPENED → RESOLVED
Closed: 3 months ago → 1 month ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.