Open Bug 2036626 Opened 20 days ago Updated 14 days ago

Should only mark temp private files as readonly if they're kept in actual tmp rather than Downloads or user-chosen directory

Categories

(Firefox :: File Handling, defect, P3)

Firefox 150
Desktop
All
defect

Tracking

()

People

(Reporter: azbalo, Unassigned, NeedInfo)

References

Details

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:150.0) Gecko/20100101 Firefox/150.0

Steps to reproduce:

I use Firefox 150.0.1 on Linux (CachyOS).
Normal Arch package, not flatpak or some custom install.

In Settings > Applications, for Content Type = Portable Document Format (PDF), the Action is "Open in Firefox".

Example of PDF download: "Basic text document" on https://sample-files.com/documents/pdf/

In NON Private mode:

  • left click => downloads and opens the PDF file in a new tab
    file permission in Downloads folder = -rw-r--r--
  • right click > Save Link as ... then click the Save button => downloads the file
    file permission in Downloads folder = -rw-r--r--

In Private mode:

  • left click => downloads and opens the PDF file in a new tab
    file permission in Downloads folder = -r-------- <<<<< WHY ?
  • right click > Save Link as ... then click the Save button => downloads the file
    file permission in Downloads folder = -rw-r--r--

Actual results:

In Private mode:

  • left click => downloads and opens the PDF file in a new tab
    file permission in Downloads folder = -r--------

This behavior is annoying because I cannot delete/send to trash the file normally since I don't have the write permission on it.
I need to use chmod +w in a terminal or rm -f to get rid of the file.

Expected results:

The file permissions on the downloaded file should be -rw-r--r-- as they are in all other cases.
Then I would be able to send the file to trash from the file manager without special commands to give me the rights or to destroy the file.

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

Component: Untriaged → PDF Viewer
Component: PDF Viewer → File Handling

Files downloads in Private Browsing are removed at the end of the PB session, unless you uncheck the "Delete private window downloads on close" option in about:preferences General. You may rely on that to cleanup files downloaded in PB.

I this the readonly setting is being applied here:
https://searchfox.org/firefox-main/rev/10725540f638ba15d8138079dab01ecbac808be5/toolkit/components/downloads/DownloadIntegration.sys.mjs#779-796
it is apparently done on purpose, though I'm not sure why we used 0400 instead of 0600

it was done by bug 1009465

(In reply to Marco Bonardo [:mak] from comment #3)

it was done by bug 1009465

If memory serves, historically temporary downloads (files which are opened in a helper app, and are stored in a directory under /tmp or equivalent) were saved readonly because this enabled better behaviour in external apps: if you tried to save them, most apps like MS word and other text editors, would realize the file was readonly and offer to save a new copy somewhere sensible (documents folder). This was better than saving-in-place because the tmp folder would get cleaned out and/or users would anyway never find the file again.

However, a few years back we changed downloads behaviour so temporary downloads now save in the downloads folder anyway (unless you set browser.download.start_downloads_in_tmp_dir). It doesn't make sense anymore to make them readonly there, as they can be easily located by users and nothing will wipe them (unless so configured by the user for private browsing specifically, which is orthogonal to the old "temporary" concept specific to files that are opened).

Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Unspecified → All
Hardware: Unspecified → Desktop
Summary: Wrong file permissions on Linux when left clicking a PDF file in Private mode → Should only mark temp private files as readonly if they're kept in actual tmp rather than Downloads or user-chosen directory

If you squint this is kind of fallout from bug 1790641, as before that change we actually deleted the files for you, whether you wanted to or not... 🙃

(but this explains for me why it has taken so "long" since the switch from tmp to Downloads folder for someone to notice this behaviour and complain - that combined with 'readonly' being a bit meaningless on Windows and macOS file pickers)

See Also: → 1790641
Severity: -- → S3
Flags: needinfo?(gijskruitbosch+bugs)
Priority: -- → P3
You need to log in before you can comment on or make changes to this bug.