User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 Requesting a way (either by hidden pref or via UI) to allow a user to specify a customisable prefix and suffix to be added to text typed into the address bar when special modifiers are used. For example, user types "sitename" in the address bar, and then uses some modifier to enter that information. Some examples of what could then happen: Presses Shift+Enter -> Opens "http://www.sitename.com/" (i.e. "http://www." + user's string + ".com/") Presses Ctrl+Shift+Enter -> Opens "http://www.sitename.net/" (i.e. "http://www." + user's string + ".net/") And so forth for various other combinations. Note 1: All of the above URL modifiers should be customisable - so you could change it to have a ".de/" suffix instead of ".com/" for Shift+Enter, for example - there is nothing special or hard-coded about ".com/", it is being used simply to illustrate the idea. Note 2: This bug is specifically **NOT** proposing to use CTRL-Enter, because that is already being used cause a new tab to be opened. Indeed, if any keyboard combinations are already used (such as CTRL-Enter) then they should not be used for this functionality - this RFE is specifically not proposing to remove or alter pre-existing keyboard combinations. Note 3: Bug 37867 included some discussion in favour of this, before it became bogged down in an unwieldy discussion focussed just on reimplementing IE's CTRL-Enter hard-coded ".com" behaviour. Due to the above 2 notes it should be clear that this RFE is trying to take what was best about those ideas, whilst avoiding the CTRL-Enter '.com'-specific baggage. Reproducible: Always Steps to Reproduce:

Excellent phrasing Nick. Considering your three notes, this is definitely a new RFE and not a dupe of Bug 37867, "Domain Guessing via keyboard shortcut (ctrl+enter) (www. .com)" 1. We don't want ctrl-enter binding 2. We don't want to default for .com TLD You got my vote.

To view an example of how another browser implements a preferences UI for this kind of functionality, please see http://www.crazybrowser.com/tour14.htm

1. Too obscure to have a prefs UI for. 2. The idea inherently has a bias for a certain TLD. Even if it is user-customizable, it is still only one TLD per user. Supporting several TLDs with several key combos is excessive and doesn't solve the underlying problem with the idea. 3. It is a bad idea in general to guess any URL. Use a search engine - it gives much more reliable and fair results. Why fair? With domain guessing, the one with the best URL gets the visit. With Google, the most popular one gets the hit. (Still not really fair, but much closer.) Once you found a URL, bookmark it and don't use the urlbar at all. Or use autocomplete, if you insist on typing. 4. BrowserLoadURI() is complicated enough already, no need for more hidden, disabled-by-default prefs. I vote for WONTFIX.

<http://bugzilla.mozilla.org/show_bug.cgi?id=37867#c188> still applies, BTW.

> 1. Too obscure to have a prefs UI for. I don't understand why, please elaborate. > 2. The idea inherently has a bias for a certain TLD. Even if it is > user-customizable, it is still only one TLD per user. Where did you read "one TLD per user"? the title of this bug specifically asks for "modifiers", hence plural TLDs. Ben, please follow your own advice and *read* the bug. > Supporting several TLDs with several key combos is excessive and doesn't > solve the underlying problem with the idea. There is no underlying problem with this idea, none whatsoever and I don't think it's "excessive" either. It's just a power-user feature that is meant for use by power-users. > 3. It is a bad idea in general to guess any URL. Use a search engine - it > gives much more reliable and fair results. Why fair? With domain guessing, > the one with the best URL gets the visit. With Google, the most popular one > gets the hit. (Still not really fair, but much closer.) Again, read the bug! Nobody asks for domain guessing, we want TLD completion ("User-customizable address bar modifiers") When I want to visit http://www.cnn.com the address is known and no guessing is needed. I just want to type cnn instead of that whole l-o-n-g string. > Once you found a URL, bookmark it and don't use the urlbar at all. Or use > autocomplete, if you insist on typing. Searching hundreds of bookmarks or using autocomlete is magnitudes slower then typing cnn + modifier. > 4. BrowserLoadURI() is complicated enough already, no need for more hidden, > disabled-by-default prefs. The whole project was is already in the state "complicated enough" from day one, should we stop improving and enhancing it?

> I don't understand why, please elaborate. Because most users couldn't care less. With our current UI, more UI prefs are worse, unless there is a strong need for them. In this case, there isn't. > "modifiers" [...] please follow your own advice and *read* the bug. The description did *not* say so clearly. I thought these were either-or examples. This would be, um, "crazy" (comment 2). Also, that "doesn't solve the underlying problem with the idea", namely that there are soon more frequently-used TLDs than keys. > Nobody asks for domain guessing One major use of this feature will be exactly that: Type word[RETURN] to get to a site about word. Like Microsoft[RETURN], verizon[RETURN] and whitehouse[RETURN] (ops!). > Searching hundreds of bookmarks Better than having hundreds of shortcuts. Organize the bookmarks. Or make the bookmarks UI better. > using autocomlete is magnitudes slower then typing cnn + modifier. What? Enable autcompletion during typing, and you only have to type cnn[RETURN]. That's even *faster*! <http://bugzilla.mozilla.org/show_bug.cgi?id=37867#c163> says it all. That's the very comment that caused (re)closure of the last bug, and IMO it applies just as well to this one.

Check this prefs: browser.fixup.alternate.prefix = www. browser.fixup.alternate.prefix = .com It would be nice to have implemented the features you describe here, I just want Ctrl+Enter to work. But after bug #37867, I noted that is really dificult to add something to the preference window or to the prefs(hidden). People don't like that kind of changes to both things. So, I wish you luck :-)

> Because most users couldn't care less. I don't agree. Bug #37867 has ~200 comments, spanning a period of two and a half years, it generated 11 patches, and it had 19 duplicate requests - and that rfe was LESS general and more case-specific than this request. That seems like an awfully large amount of effort for something that people don't care about. > namely that there are soon more frequently-used TLDs than keys. That's true, but that's not the point. The point is that by being customisable, that a user can configure it so that it does what matters most to them. That could be adding a TLD, or it could be something like searching google, or something else entirely - it's up to the user. It's supposed to be blazingly fast to use, and to be configurable, and therefore powerful.

As an idea/suggestion to help facilitate discussion, maybe there's a way to implement this that uses bookmarks instead of using preferences. I'm attaching a mock-up showing something like this in the bookmark properties dialog box, so as to illustrate the general idea. Something like keywords on steroids, that can hopefully use all the existing keyword infrastructure, but be even faster. Please note that as with the link to the example link given above, this is purely intended to show one possible approach to resolving this (i.e. it could be done this way, not it should be done this way).

Shouldn't this live in the URL Bar component?

I agree that all suffixes should be editable, There's also a thread about it on mozillazine: http://forums.mozillazine.org/viewtopic.php?t=19787&postdays=0&postorder=asc&start=0

For this feature in Firefox, see bug 221161.

*** Bug 77740 has been marked as a duplicate of this bug. ***