Open foolip opened 6 years ago
Another failed attempt:
/Applications/Safari\ Technology\ Preview.app/Contents/MacOS/safaridriver -p 9999
curl -d '{ "capabilities": {} }' http://localhost:9999/session
{"value":{"sessionId":"78FFD008-96EB-4C4E-B6B9-0BB7AA732F85","capabilities":{"browserVersion":"12.1","platformName":"macOS","acceptInsecureCerts":false,"setWindowRect":true,"browserName":"Safari Technology Preview"}}}
@burg, how would you advise people to get the STP release number if it wasn't installed from a known dmg? (Which I am currently doing, I believe @jugglinmike has told you that safaridriver doesn't work in STP 66, hence the 65 in this issue.)
@burg https://bugreport.apple.com/web/?problemID=43691655 is filed on the inability to get the STP release number programmatically FWIW
Safari Technology Preview 67 and later has added the --version flag to safaridriver. Let me know if that doesn't solve your needs.
Wonderful, thanks @burg!
I don't see 67 on https://developer.apple.com/safari/download/ yet, do you know when it will be released, @burg? Thanks!
You could also check the WebKit blog. Looks like version 67 hasn't been announced yet.
Also, Brian: the ATOM feed and the RSS feed are both out of date (they list the announcement of STP 62 as the latest post).
It's here: https://webkit.org/blog/8419/release-notes-for-safari-technology-preview-67/
I've sent https://github.com/Homebrew/homebrew-cask-versions/pull/6387 for my own use, and verified that safaridriver --version
outputs this:
Included with Safari Technology Preview (Release 67, 13607.1.9.0.1)
@burg, do you also know what that string will be in Safari stable? I'm asking because I'm updating ./wpt run
to extract the string and would like to be proactive.
Example:
bburg$ safaridriver --version Included with Safari 12.1 (14607.1.11)
The version string has been explicitly designed to be regex parsable. Let me know if you think this is problematic; I've used it internally with pytest to write Safari Technology Preview-specific tests.
Thanks @burg! https://github.com/web-platform-tests/wpt/pull/13467 is where I'm writing the code to parse it, although I haven't finished it.
BTW, 12.1 doesn't show up in the string for STP, but it is the version that PlistBuddy will report. Do you consider part of the version, or just an internal detail?
12.1 is also in the UI screenshot I posted.
Safari Technology Preview's Info.plist will list the next anticipated Safari release version, to signal that it is not Safari 12 (in this case). However I omit that from the version output as we typically don't reference that version string for Safari Technology Preview. There is no other programmatic way to determine the STP release from the Safari Technology Preview app.
Thanks for the explanation, then so think just stripping "Included with " in both cases to get "Safari Technology Preview (Release 67, 13607.1.9.0.1)" and "Safari 12.1 (14607.1.11)" is fine.
@jugglinmike, would you know why 12.1 shows up as the version for STP on wpt.fyi now? Did you use PlistBuddy?
@lukebjerring, will we need to adapt the wpt.fyi frontend to this as well? And can we change the version information retroactively to not have 12.1 ever match STP?
When running Safari locally, the system infers the version based on files that are "near" the executable under test. The heuristic is implemented and explained in the read-browser-version.py
script. Relevant comment:
# The Safari binary cannot be queried for this information. Because it may
# only be installed at the system level, this function operates on
# assumptions regarding files that are present relative to the binary.
# The XML-formatted `version.plist` file contains key/value pairs in the
# following structure:
#
# <plist version="1.0">
# <dict>
# <key>EXAMPLE KEY</key>
# <string>EXAMPLE VALUE</string>
# </dict>
# </plist>
#
# See:
# https://developer.apple.com/library/content/documentation/General/Reference/InfoPlistKeyReference/Articles/AboutInformationPropertyListFiles.html#//apple_ref/doc/uid/TP40009254-SW1
You might say we're our own PlistBuddy
Aha, well that explains it at least. And means that when wpt can get the version from safaridriver --version
, that some tweaks around this to not override will also be needed.
@jugglinmike, do you know which exact STP versions have been used for which runs, so we could retroactively edit the version info?
We've tested the latest version for almost every collection. The exception is we tested STP 65 until STP 67 was released because version 66 could not be automated. Relevant data is available in the build logs, so I can verify programtically when/if that's desirable.
Great, thank you! @lukebjerring, do you think we should just edit the version information in wpt.fyi's datastore, or will something bad happen if the information is out of sync with the reports? We could just leave it, but downside is that product=safari-12
can match the wrong thing for some shas, which is a problem I actually ran into.
Yes; I'll defer to @Hexcles for a batch-update of mapping the (incorrect) data
The raw report for the latest run has
"browser_version": "12.1"
. This is also what shows up on wpt.fyi.In the UI a much more detailed version string ("Release 65 (Safari 12.1, WebKit 13607.1.5.2)") is available:
Knowing the release number (65) and when it changes is important for comparing results over time.
Unfortunately,
/usr/libexec/PlistBuddy -c Print /Applications/Safari\ Technology\ Preview.app/Contents/Info.plist
doesn't include the "65", but it does include "13607.1.5.2" as CFBundleVersion.P.S. This issue is similar to https://github.com/web-platform-tests/wpt/issues/13052 and https://github.com/web-platform-tests/wpt/issues/13399, and the solution may be in wpt itself, but also perhaps not given that much of the Safari-specific setup is in this repo.