User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:109.0) Gecko/20100101 Firefox/113.0

Steps to reproduce:

open inspector developer tool for a website
choose a node, right-click choose screenshot node

Actual results:

heard the click, saw the flash, but no image file was written the downloads folder

Expected results:

In the past, there would be a PNG file containing the screenshotted node in my downloads folder. This stopped working a month or two ago.

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.

Hi,

I wasn't able to reproduce the issue on my end. It successfully created a screenshot of the node on my end.

When the resulting image is too large you should get an error notification right above the devtools, but nor the click sound nor the screenshot flash occurs if that is the case.

Could you check if this also occurs in troubleshooting mode? Here is a link to help you with that: https://support.mozilla.org/en-US/kb/diagnose-firefox-issues-using-troubleshoot-mode#w_how-to-start-firefox-in-troubleshoot-mode

Thanks!

Unless this issue also reproduces using the screenshot browser feature ("Take Screenshot" context menu item, toolbar button, ctrl+shift+s keyboard shortcut) we should track this under devtools.

the "Take Screenshot" context menu item works normally for me

(In reply to Peter Magyari (Desktop QA) from comment #2)

Could you check if this also occurs in troubleshooting mode?

It is exactly the same in troubleshooting mode.

I found the issue. Firefox is saving the screenshots to ~/Pictures instead of ~/Downloads like before. I have no idea why. Is there a setting somewhere that controls this?

it's unintuitive and inconsistent that the context menu saves them to one place, and the developer tools saves them in another.

(In reply to exekutive from comment #6)

I found the issue. Firefox is saving the screenshots to ~/Pictures instead of ~/Downloads like before. I have no idea why. Is there a setting somewhere that controls this?

This was done in Bug 1072345 and there's some rationale there.
I agree that the context menu and devtools should save to the same place, so maybe we could also change where the context menu stores the screenshot

I actually preferred the Downloads directory. It's quicker to access, and MacOS flashes an animation that a new file was saved there. You can actually click the animation to immediately open the file in Preview without having to browse for it.

Sam, do you have opinion on this? See Bug 1072345 for the rationale on why scrrenshots from devtools were moved to Pictures folder

The Screenshots UI has "copy" and "download" buttons. I don't think I don't feel strongly about which directory it ends up in - in principle - but we actually call the browser.downloads extension API to "download" the file, which triggers the download animation and highlight on the download toolbar button. So we would want to change the UI if we also changed the target, and we would need to replace those "success" cues. I'm not sure there's a clear argument either way but I'm happy to be convinced. We could certainly add a pref to allow a user to change their default to match that of devtools' screenshots.

The plan is to add a Screenshots block under the "General" preferences to choose where to save screenshots, and use that value when downloading a screenshot (saving to the filesystem.) Devtools could then potentially use the same pref value if we want consistency.

The product::component has been changed since the backlog priority was decided, so we're resetting it.
For more information, please visit BugBot documentation.

Thanks for that bot 😬

Hey there! So I think I'm to blame for this bug 😅. I noticed the behavior changed in 127 and found this issue.

I'd be interested in picking up the task if available, but had some quick questions on the expected behavior.

My initial thought is to create a preference with three options: Downloads folder, Screenshots folder or Custom. Does this approach make sense? I suppose the alternative is to default to either the downloads or screenshots directory and allow an override. I would lean towards the former since as someone who takes a lot of OS and Firefox screenshots being able to keep them in sync is a nice feature.

I would also apply the same preference to both the devtools command and screenshot button. Or is there a use case where one would expect different behavior?

I think we still need to figure out what the right solution is here. In principle, having a pref which saves to one of the special, environment-defined folders like Pictures or a custom directory seems reasonable. devtools could then use the same path - we are agreed that its reasonable to expect screenshots to be saved the same way across both features. But, I'm not a big fan of adding preferences without corresponding UI which most users will never find. And its not clear where this UI would go. Mabe a new block in about:preferences#general under the Files and Applications section. Or do we createsomewhere in the Screenshots UI? And what should the choices be for each of the major platforms we support: Windows 10+, MacOS and linux.

If we can nail down answers to some of these questions, I'd be happy to review and land a patch!

And what should the choices be for each of the major platforms we support: Windows 10+, MacOS and linux.

I started to do a bit of research on this topic. For MacOS, the default save directory is the desktop and it is controlled by the com.apple.screencapture location preference. As part of the previous bug, this value is read in SpecialSystemDirectory.cpp.

On Windows, the default directory looks to be Pictures\Screenshots. There is also a knownfolderid for this directory so I think this value could be read in the same way as the Downloads folder.

For Linux, I imagine it's much more varied and depends on the distro and desktop environment. From what I can tell Gnome uses XDG_PICTURES_DIR (typically ~/Pictures), but it may have recently used XDG_PICTURES_DIR/Screenshots. https://help.gnome.org/users/gnome-help/stable/screen-shot-record.html.en

Unfortunately, I only have a Mac handy so I'm not able to test the other platforms at the moment. I'm just relying on documentation.

So one option is to use those OS-defined directories as a default location. So the user is choosing between "Your download folder" and "Choose..." which opens a file picker at the best-guess default directory for their platform. Again, I'm not sure of the UX, but limiting the number of choices to pick from would be good. I guess the profile becomes a bit more portable if the stored value is resolved to a directory at runtime, rather than populating a pref with the actual filesystem path in the case of the knownfolderid and MacOS/Linux equivalents. That's more likely to survice a OS upgrade.

Yeah I also think resolving at runtime makes the most sense.

I've been trying out an approach based on how the downloads prefs work. browser.download.folderList allows selecting Desktop, Downloads or Custom with Custom using the directory in browser.download.dir. The idea is to have browser.screenshots.folderList/dir behave the same with the additional option of the Screenshots directory.

So far this seems to work well, but I'm a bit unsure of the preferences UX. With Downloads, the way it appears to work is that when the user selects a directory in the filepicker which corresponds to the system's Desktop or Downloads directory, it sets the corresponding value in folderList instead of saving the full path. The correct directory is then resolved at runtime.

This behavior is kind of hidden though. The same strategy could work for the system Screenshots directory, but I think a more explicit UX would help. My rough idea is a checkbox below the file input which when enabled sets the folderList pref to use the system screenshots directory. It might also disable the file input and show the current path of the screenshots directory there.