Help: `ShowUrl` events should provide some feedback on invalid URLs

[DavisVaughan]

Run the following R code...nothing happens whatsoever.

browseURL("www.google.com")

This is an invalid url, and should instead be browseURL("https://www.google.com"). But we should provide some kind of feedback in this case. I sat there waiting for it to open and thought it was broken on the Positron side.

Maybe a toast notification or something?

[jennybc]

With #8588 and posit-dev/ark#877, this becomes an OS problem and on macOS browseURL("www.google.com") causes this:

This is probably not a complete or ideal solution? But there is some feedback now. With RStudio, I also seem to get radio silence, FWIW.

Here's what you see in R in a terminal (no IDE involved)

> browseURL("www.google.com")
> The file /Users/jenny/tmp/www.google.com does not exist.
Perhaps you meant 'http://www.google.com'?

This really boils down to whose job it is to provide a better error message. This input doesn't look enough like a URL to be processed as such and is therefore treated as a file path. VS Code's opener service does not handle such an error. So if we think better feedback is necessary, it could happen in Positron in the handling of UiFrontendEvent.OpenWithSystem. Or, arguably, it should happen in ark's ps_browse_url() function, which is what ark routes getOption("browser") into. Maybe ark should catch file non-existence before sending the event?

[DavisVaughan]

I don't think I mind an os error in this particular case with OpenWithSystem because we don't really know which system command is going to try and do something with it

[jennybc]

I'm glad to hear this opinion @DavisVaughan. The VS Code / Positron opener service does a fair bit and, in particular, handles more than plain old file paths (even though that's our overwhelming assumption about what we're sending it from ps_browse_url()). I think it's best to keep our "this is file path" assumption more implicit than explicit and just send things over that we don't clearly recognize as a case we want to handle (currently, help URLs and local .html files).

Does this mean we can close this? I don't think we have any concrete plans for further improvements at this time.

[DavisVaughan]

I vote yes