Starting with node-chrome:3.141.59-20200719 downloading a file in Chrome bring up a modal/prompt asking for the save location. This error does not occur in node-chrome:3.141.59-20200525 and lower. Not sure if it coincides with a few other changes in the 3.141.59-20200719 image. Chrome was also bumped from v83 to v84. But when I test locally with v84 I can still do silent downloads.
Chrome options that enable prompt-less downloads -
Map<String, Object> chromePrefs = new HashMap<>();
ChromeOptions options = new ChromeOptions();
chromePrefs.put("download.default_directory", downloadPath);
chromePrefs.put("download.prompt_for_download", false);
options.setExperimentalOption("prefs", chromePrefs);
MutableCapabilities chromeCapabilities = new MutableCapabilities();
chromeCapabilities.setCapability(ChromeOptions.CAPABILITY, options);
Worked up to version: 3.141.59-20200525
Stopped working in version: 3.141.59-20200719
Steps to reproduce the behavior:
I should be able to download a file without the save-as prompt/modal from a web page in Chrome inside a running docker-selenium container.
OS:
Docker-Selenium image version: node-chrome:3.141.59-20200719
Also provide the docker image id: sha256:1b785fed01399256af34748d77dbb4853646ccafe2d5506f75d10ad3f97e663c
Docker version: 18.09.3, build 774a1f4
Docker-Compose version (if applicable):
Exact Docker command to start the containers (if using docker-compose, provide
the docker-compose file as well):
I use a Docker Swarm setup which is a little more involved. Will be happy to share commands if absolutely needed for troubleshooting.
@testphreak is it possible to have a complete script to reproduce the issue? I don't have a website where I can download something.
@diemol sorry it took me a few days to get back on this issue. I was able to dig deeper into the issue and figure out the problem. The failed downloads are directly due to the change made by @srguglielmo to use a numeric user instruction in Dockerfiles. The issue had nothing to do with Chrome specifically as I previously thought. I suspect pretty soon, others in this community who download files, like here, and are still on older versions of the images will start seeing issues as they update to the latest.
The downloads fail due to insufficient permissions when files are saved on mounted volumes and the hosts are Linux. In my case the volume was mounted as user ubuntu with uid/gid 1000:1000. The files in the latest Docker images are run inside containers with uid/gid 1200:1201 causing the errors. Downloads worked on MacOS but not on Ubuntu which made the issue confusing. While I realize the change was made to adhere to best practices; due to this long standing issue, mounting of volumes by users other than root is still not supported by Docker.
Posting my solutions here, for when others run into this issue -
User inside the container as 0 (root) which downloads the file with owner/group as root. Next chown/chgrp the files to your host user, in my case ubuntu, to do some post-processing on those files.seluser with user id 1200 and group 1201 to match the uid and gid set in the latest Docker images. Going with this option is a bit more involved, but is cleaner and eliminates the need to chown/chgrp the files or run container as root.@testphreak thanks a ton for opening this issue, digging into it and proposing solutions!
I can confirm downloads were not working anymore since 3.141.59-20200719 but your solution works fine!
Most helpful comment
@diemol sorry it took me a few days to get back on this issue. I was able to dig deeper into the issue and figure out the problem. The failed downloads are directly due to the change made by @srguglielmo to use a numeric user instruction in Dockerfiles. The issue had nothing to do with Chrome specifically as I previously thought. I suspect pretty soon, others in this community who download files, like here, and are still on older versions of the images will start seeing issues as they update to the latest.
The downloads fail due to insufficient permissions when files are saved on mounted volumes and the hosts are Linux. In my case the volume was mounted as user
ubuntuwith uid/gid1000:1000. The files in the latest Docker images are run inside containers with uid/gid1200:1201causing the errors. Downloads worked on MacOS but not on Ubuntu which made the issue confusing. While I realize the change was made to adhere to best practices; due to this long standing issue, mounting of volumes by users other than root is still not supported by Docker.Posting my solutions here, for when others run into this issue -
Userinside the container as0(root) which downloads the file with owner/group as root. Nextchown/chgrpthe files to your host user, in my caseubuntu, to do some post-processing on those files.seluserwith user id1200and group1201to match the uid and gid set in the latest Docker images. Going with this option is a bit more involved, but is cleaner and eliminates the need tochown/chgrpthe files or run container asroot.