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
# Issue report:
If you enter a URL without a scheme, such as "www.google.com", the extension does not currently work. (At least not on my machine.)
People are accustomed to modern browsers and search bars automatically adding a scheme component to any URLs that are missing them. (I just tested, and the chrome browser appears to add the "https://" prefix by default. Using "https" as a default seems okay because it looks like the most popular homepages do support secure connections.)
# Suggested fix:
When a user submits a target URL, search the submitted string for this substring: "//:" If the substring is present, then do nothing. If the substring is absent, then automatically add the following substring to the beginning of the URL: "https://".
I'm not certain if the above suggestion is the most comprehensive way to handle the problem, but I imagine it should fix the most common cases. For example it will change "Google.com" to "https://Google.com", which will function as the user expects.
The only (small) problem I can see with the above fix is that some pages will not support the https protocol. (Some older sites may only support http.) With that in mind, below are a couple alternative fixes.
# Alternative fix 1:
If the user enters a target URL that does not include a scheme, then do not accept it and display an error.
# Alternative fix 2:
Include instructions on the Target URL entry page, saying all URLs must include a scheme. Include an example. You could say something like "All URLs must include a scheme prefix. For example: "https://www.google.com" is fine, but "www.google.com" alone will not work." I've supplied an implementation of this possible fix, in a different this message in this thread (below).
-Blake
The text was updated successfully, but these errors were encountered:
Here's an informal patch for implementing alternative fix number 2. You could add/apply the following text to the file "options.html". I have included surrounding text, to indicate the position of the suggested change.
<p>
Type "<tt>Ctrl-Enter</tt>" to save.
</p>
<p>
Important: The target URL must include a scheme prefix. For example, "https://www.google.com" is fine, but "www.google.com" by itself will not work.
</p>
<p>
This extension includes a built in <a href="blank.html">blank page</a> which can be used (if you can
tolerate ugly URL).
</p>
# Some definitions for the sake of conversation:
URLs that include a scheme: "https://www.google.com" or "http://www.google.com"
URLs without a scheme: "www.google.com" or "google.com"
(For more details, see also: https://en.wikipedia.org/wiki/URL#Syntax)
# Issue report:
If you enter a URL without a scheme, such as "www.google.com", the extension does not currently work. (At least not on my machine.)
People are accustomed to modern browsers and search bars automatically adding a scheme component to any URLs that are missing them. (I just tested, and the chrome browser appears to add the "https://" prefix by default. Using "https" as a default seems okay because it looks like the most popular homepages do support secure connections.)
In this extension, incomplete URLs do not open a webpage, so some people are going to think the extension is broken. This is already happening on the extensions support page. See the "broken" reports at: https://chrome.google.com/webstore/detail/new-tab-url/njigpponciklokfkoddampoienefegcl?hl=en-US
# Suggested fix:
When a user submits a target URL, search the submitted string for this substring: "//:" If the substring is present, then do nothing. If the substring is absent, then automatically add the following substring to the beginning of the URL: "https://".
I'm not certain if the above suggestion is the most comprehensive way to handle the problem, but I imagine it should fix the most common cases. For example it will change "Google.com" to "https://Google.com", which will function as the user expects.
The only (small) problem I can see with the above fix is that some pages will not support the https protocol. (Some older sites may only support http.) With that in mind, below are a couple alternative fixes.
# Alternative fix 1:
If the user enters a target URL that does not include a scheme, then do not accept it and display an error.
# Alternative fix 2:
Include instructions on the Target URL entry page, saying all URLs must include a scheme. Include an example. You could say something like "All URLs must include a scheme prefix. For example: "https://www.google.com" is fine, but "www.google.com" alone will not work." I've supplied an implementation of this possible fix, in a different this message in this thread (below).
-Blake
The text was updated successfully, but these errors were encountered: