Safari requires user intervention to proceed

[jobara]

In Safari 13 on macOS 10.15 (Catalina), the user is required to confirm the start.html file being loaded into the browser before the tests will proceed. This is likely causing the tests to hang and timeout when running in the macOS runner on GitHub Actions.

To reproduce on macOS 10.15:

1. checkout the testem repo.
2. Install all dependencies
3. Change to the examples/qunit_simple directory
4. Run the command node ../../testem.js ci --file testem.json --launch Safari

Notice that when Safari is opened, the file open dialog is opened and requires the user to confirm or cancel the file to load.

[step2yeung]

@jobara Thanks for reporting this!
Don't have time yet to dive into this issue, @jobara would you have time to help dive deeper?

[jobara]

@step2yeung I don't have a lot of time to look into this either, but I did spend a bit of time poking around. I wasn't able to locate any information about the CLI arguments/parameters for calling Safari. Do you know where there might be information on this?

From testing with a static file I was able to find that if you accept the prompt once, it won't ask you again for the same file. But with the random temp folders used by testem, it doesn't seem like something that could even be used as a work around.

I have seen most people using open -a Safar <url> to trigger Safari from the command line. I haven't had success integrating that with Testem. Perhaps testem is using the possible paths to also determine if the browser is available? However, this seems to be where you'd need to specify open as the application to execute. And, or course, this would only work on macOS. Although I don't think Safari is supported on Windows anymore.

[jobara]

@step2yeung perhaps this open issue from the karma safari launcher might provide some helpful information. karma-runner/karma-safari-launcher#29

[jmonster]

Perhaps we could have an alias in a static location that gets updated to point to to the temp folder on run? Perhaps Apple is clever enough to catch this, though...

Not a great solution, either way.

[raido]

I have ran into this as well with Github Actions VMs and locally as well. There's something for Karma via AppleScript to workaround this. https://github.com/brandonocasey/karma-safari-applescript-launcher.

[ef4]

I have a workaround that you can put in your testem config. This works both locally for me on Big Sur and on GitHub Actions macos-latest.

launch_in_ci: ['SafariApplescript'],
launchers: {
    SafariApplescript: {
      protocol: 'browser',
      exe: 'osascript',
      args: [
        '-e',
        `tell application "Safari"
          activate
          open location "<url>"
         end tell
         delay 3000`,
      ],
    },
  },

The delay is there because osascript will otherwise exit immediately, causing testem to think the browser has exited and end too early.

[ef4]

We could upstream this directly as the launcher for Safari in testem, but I'm not sure what the best way to do it properly (without the arbitrary delay) would be.