Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CEF force-creates a Downloads directory in user directory #3094

Closed
magreenblatt opened this issue Feb 22, 2021 · 7 comments
Closed

CEF force-creates a Downloads directory in user directory #3094

magreenblatt opened this issue Feb 22, 2021 · 7 comments
Labels
alloy Related to the Alloy runtime bug Bug report Framework Related to framework code or APIs

Comments

@magreenblatt
Copy link
Collaborator

Original report by Henri Beauchamp (Bitbucket: Henri Beauchamp).


Greetings,

In recent CEF versions (v81+, at least), CEF force-creates a “Downloads” directory when launched, even though:

  • Such a directory is not needed at all for applications not allowing to download anything via CEF (e.g. the Second Life viewer), and yet CEF creates it even before any download is requested.
  • The algorithm to determine whether a downloads directory is “safe” or not is totally flawed (why the Hell would the home user directory be considered “dangerous” at all ?).
  • It is NOT the business of an application to decide what the directory tree of a user should be.

The culprit code is (currently, i.e. for CEF v88) in chromium_git/cef/libcef/common/resource_util.cc, namely the DownloadPathIsDangerous() function.

I suggest that at least one of the following fixes is applied to future CEF versions (in preference order):

  • Remove that function altogether and let the it be user's responsibility to choose how they manage their own files.
  • Make the DownloadPathIsDangerous() check only active following the activation of a runtime option.
  • Instead of creating a Downloads directory, and when the current directory is considered “dangerous”, point the default download path to a “safe” directory (e.g. the one pointed by $TEMP) as a suggested destination.
  • Offer an option to disable entirely the DownloadPathIsDangerous() check at runtime.
  • Keep creating the “Downloads” directory, but only when a download is actually attempted !

Thank you.

@magreenblatt
Copy link
Collaborator Author

Original changes by Henri Beauchamp (Bitbucket: Henri Beauchamp).


  • edited description

3 similar comments
@magreenblatt
Copy link
Collaborator Author

Original changes by Henri Beauchamp (Bitbucket: Henri Beauchamp).


  • edited description

@magreenblatt
Copy link
Collaborator Author

Original changes by Henri Beauchamp (Bitbucket: Henri Beauchamp).


  • edited description

@magreenblatt
Copy link
Collaborator Author

Original changes by Henri Beauchamp (Bitbucket: Henri Beauchamp).


  • edited description

@magreenblatt
Copy link
Collaborator Author

It’s the call to base::PathService::Override in OverrideDefaultDownloadDir that creates the directory. The viable alternatives include:

  1. Using a different path (like TEMP) if the safe directory does not already exist.
  2. Using OverrideAndCreateIfNeeded instead of Override to create the directory later, if needed. This will require testing to verify that it works as expected with the code in chrome/browser/download/download_prefs.cc.

A PR is welcome if you would like to implement this.

@magreenblatt
Copy link
Collaborator Author

  • changed title from "CEF force-creates a Donwloads directory in user directory" to "CEF force-creates a Downloads directory in user directory"

@magreenblatt
Copy link
Collaborator Author

Alloy bootstrap is removed in M128 (see #3685)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
alloy Related to the Alloy runtime bug Bug report Framework Related to framework code or APIs
Projects
None yet
Development

No branches or pull requests

1 participant