It looks as though sudo safaridriver --enable doesn't work again, similar to in #19845. The error is "SessionNotCreatedException: session not created (500): Could not create a session: You must enable the 'Allow Remote Automation' option in Safari's Develop menu to control Safari via WebDriver."

Looks like TaskCluster didn't run here, retrying.

Looks like TaskCluster didn't run here, retrying.

This is a draft PR, TaskCluster doesn't run on drafts.

Unfortunately at this point we're quite stuck on this issue. Folks from Apple have been unable to figure it out even with additional logging:

I am unable to reproduce the Azure issue on a vanilla customer build with Safari Technology Preview 108.
If I had to guess, something weird is going on, such as running safaridriver via a non-UI shell
or weird permissions to ~/Library/
Unfortunately no error is returned on the file write operation, so it's hard to say what it thinks is going on.

We've tried various things to make the plist file appear, but it just won't. Without ssh-access to the bots for interactive debugging, we're rather out of options.

To guard against 'what happens when Catalina becomes the default MacOS', I guess we should experiment and see if we can use a workaround plist file again.

I tried to reproduce it locally and failed, but had some interesting observations.

~/Library/WebDriver seems super special from the perspective of a Linux user. The directory did not exist until I ran sudo "/Applications/Safari Technology Preview.app/Contents/MacOS/safaridriver" --enable, which created the directory that belongs to me (the primary user) instead of root:

ls -ld ~/Library/WebDriver
drwxr-xr-x  3 robertma  primarygroup  96 12 Jun 15:25 /Users/robertma/Library/WebDriver

However, I cannot cd or ls it. I tried a root shell (via sudo -i) and I could cd into it but still couldn't ls. I managed to open it in Finder (Library is hidden by default in Finder) and found com.apple.SafariTechnologyPreview.plist in there, which I was able to open with VSCode:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>AllowRemoteAutomation</key>
	<true/>
</dict>
</plist>

Even with the full path name, I still can't access the file in a terminal at all.

If we suspect something is wrong with this plist, how can we debug it in a script? I don't think our current attempt of ls -l -@ ~/Library/WebDriver is useful if we can't even open it.

Well (sigh) the plist hack that we used to use appears to work again (aka copy the plist @Hexcles provided instead of calling safaridriver --enable).

I'm going to try a 'clean' version of this PR and push it to safari triggers to confirm.

Well (sigh) the plist hack that we used to use appears to work again (aka copy the plist @Hexcles provided instead of calling safaridriver --enable).

Or... maybe it doesn't. Still a bunch of errors in the infra tests, just less familiar ones (NoSuchFrameException: no such frame (404):, JavascriptErrorException: javascript error (500): A JavaScript exception occured: window.__wptrunner_process_next_event is not a function. (In 'window.__wptrunner_process_next_event()', 'window.__wptrunner_process_next_event' is undefined), ...).

obsoleted by #24812