2

So I've been searching SO (and various other sites) regarding the issue of Protractor not supporting control and manipulation of "save as" dialogs when downloading files.

I've learned that I need to specify download prefs similar to the code snippet below, specifying "default_directory" as an absolute path. 

chromeOptions: {
    // Get rid of --ignore-certificate yellow warning
    args: ['--no-sandbox', '--test-type=browser'],
    // Set download path and avoid prompting for download even though
    // this is already the default on Chrome but for completeness
    prefs: {
        download: {
            prompt_for_download: false,
            default_directory: '/e2e/downloads/',
        },
    },
},

However, I have 2 problems in one. Firstly, this works fine in my Linux based Protractor environment. I can specify /any/absolute/path/I/want and then download to that folder without issue, and without a "Save As" dialog appearing. If I try this in my Windows Protractor environment, with say 'default_directory: 'c:\\some\\folder\\' (where that path exists!) It doesn't work - the dialog appears, and the prompted folder isn't as specified in my conf.js file. I've tried replacing the double backslashes with single (not good!), and even with forward slashes.... No variant of any valid windows path works? What am I getting wrong?

Also, is there any way of specifying 2 sets of chromeOptions - and have protractor automatically use the appropriate set according to the host OS? Ie, so I can have 2 default_directory values - one Linux, one Windows, without having to continually comment one or the other out at run time?

Steve Hall
  • 469
  • 1
  • 5
  • 23
  • What if you add `directory_upgrade: true` like suggested [here](http://stackoverflow.com/a/28868885/771848)? – alecxe Apr 12 '16 at 13:27
  • 1
    you can use a javascript ternary operator or function to vary the chrome options... `chromeOptions: os.platform() === 'win32' ? {..win32 options..} : {...linux opts...}` https://nodejs.org/dist/latest-v4.x/docs/api/os.html#os_os_platform – Jesse Apr 13 '16 at 05:28
  • Sorry for the slow response... @alecxe - Sadly that doesn't make a difference. – Steve Hall Apr 20 '16 at 07:22
  • @Jesse - thanks for that - I assume "win64" is an equally valid value? – Steve Hall Apr 20 '16 at 07:23
  • 1
    @SteveHall based on my digging it looks like the 'win32' string will be returned for 64bit windows systems as well.. so checking for win64 would not work.. – Jesse Apr 21 '16 at 17:04

0 Answers0