You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Sep 18, 2019. It is now read-only.
When interpreting an URI parameter in the command line without the http:// or https:// prefixes, Dinghy could:
Use the parameter as a file system path. If a readable file exists, turn it into a file:// URI with an absolute path, and load that instead.
Otherwise, try adding http:// to the URI, and load that instead.
Just doing the two steps above would make things much more convenient and work in 99% of the cases because most services behind HTTPS have HTTP-to-HTTPS redirections.
The text was updated successfully, but these errors were encountered:
Passing a path is already working, g_file_new_for_commandline_arg(), the only thing missing is to check for file existence, and trying to turn it into an http:// URI if there wasn't an URI scheme already there.
Instead use WebKitWebView::web-process-terminated, which provides
additional information about the reason of the process termination.
The termination reason is used to format the messages and error
pages, but other than that the behaviour of the updated code remains
the same.
Fixes#3
Instead use WebKitWebView::web-process-terminated, which provides
additional information about the reason of the process termination.
The termination reason is used to format the messages and error
pages, but other than that the behaviour of the updated code remains
the same.
Fixes#3
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
When interpreting an URI parameter in the command line without the
http://
orhttps://
prefixes, Dinghy could:file://
URI with an absolute path, and load that instead.http://
to the URI, and load that instead.Just doing the two steps above would make things much more convenient and work in 99% of the cases because most services behind HTTPS have HTTP-to-HTTPS redirections.
The text was updated successfully, but these errors were encountered: