Affects Version/s: 3.3.7, 3.4.4, 3.5.1, 3.6
Fix Version/s: None
Affected Branches:MOODLE_33_STABLE, MOODLE_34_STABLE, MOODLE_35_STABLE, MOODLE_36_STABLE
When you click on the "Download" button of a file in filepicker (see screenshot), the filepicker creates an invisible iframe from which the download is served: https://github.com/moodle/moodle/blob/c7d148dc202ea5667a04b8677df8b6f3b9182fc9/lib/form/filemanager.js#L809.
This seems like a rather clean approach because it doesn't open new tabs, however, this leads to issues with some repositories:
- In some cases (e.g. ownCloud/Nextcloud with "external link"), the file is actually served from the remote system; i.e. the repository's send_file method is implemented to redirect the user to a URL in the remote system. However, for security reasons Nextcloud always adds the header "X-Frame-Options SAMEORIGIN", thus preventing anything from being embedded within an iframe. As a consequence, the download never starts and the user does not know why.
- In other cases (e.g. ownCloud/Nextcloud with "access controlled link") the user has to sign into oC/NC first. That is, if she tries to access a file but is not logged in, the button "Log in to ... " is shown that can be used to open a popup for authentication. On successful authentication, the user is redirected to the original URL and the file can be shown. However, the button is not visible in the iframe, due to it being hidden.
The file is shown or downloaded from the remote URL (case 1), or the login button is shown (case 2).
Both issues would be resolved by opening the resource in a new tab (instead of in the iframe): The SAMEORIGIN header would not apply, resulting in the file being shown, and the login button would be clearly visible to the user.
For all other cases this should not be a problem either, as browsers usually close tabs automatically if they were just used for downloading a file (and do not display any content on their own).