It’s already supported in Firefox, but you have to explicitly enable the partial support in Chrome’s settings and it’s completely unsupported in some other browsers, so I’ll wait a while until browser support is improved.
linkStackTrace obviously doesn’t work without JS, but I don’t think that’s obvious to everyone. We should have a <noscript> “Sorry, you need JS” kind of message.
Blocking the UI thread for the search is Really Bad™. I’ll need to think a bit about how we preserve the order of the stack trace, but it should definitely be possible.
We could offer a feature to replace the “latest” commit-ish SHA that the GitHub Search uses in the file URL with a user-provided commit-ish, for example a release tag. The line numbers should always match the version of the program that the stack trace is from, and many users might not be running the latest version. As long as no files were moved, simply replacing the SHA should work fine.
However, I don’t want to break the workflow “Ctrl+V, Tab, userRepo, [optional Tab], Enter” by inserting another UI element. I’ll have to think about that a bit.
When using v3 of the GitHub API, search by user/repo doesn’t work (total_count 0). Avoided for now by reverting to beta version in 828bd8e, but that will probably be discontinued eventually, so I have to find out why it broke.
With the fully qualified method name, the stack trace is usually too wide for GitHub issues. It would be great if we offered the option to strip the package name.
“stacktrace” is only written as one word in German, it seems. Dangit.
I’ll keep the name ”linkStacktrace” (instead of “linkStackTrace”) for the repository, website, and js function (I think), but I’ll have to change the occurrences in text.