Skip to content
This repository has been archived by the owner on Sep 18, 2019. It is now read-only.

Be smarter about URIs and file paths passed in the command line #3

Closed
aperezdc opened this issue Mar 5, 2018 · 1 comment
Closed
Assignees

Comments

@aperezdc
Copy link
Member

aperezdc commented Mar 5, 2018

When interpreting an URI parameter in the command line without the http:// or https:// prefixes, Dinghy could:

  1. 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.
  2. 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.

@aperezdc
Copy link
Member Author

aperezdc commented Mar 5, 2018

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.

@aperezdc aperezdc self-assigned this Mar 5, 2018
aperezdc added a commit that referenced this issue May 14, 2018
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
aperezdc added a commit that referenced this issue Jul 20, 2018
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 free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

1 participant