175238 - RFE: User-customisable address bar modifiers

Status: NEW

(SeaMonkey :: Location Bar, enhancement)

Description

[Nick_Jenkins]

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:

Comment 1

[Prognathous]

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.

Comment 2

[Nick_Jenkins]

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

Comment 3

[Ben Bucksch (:BenB)]

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.

Comment 4

[Ben Bucksch (:BenB)]

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

Comment 5

[Prognathous]

> 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?

Comment 6

[Ben Bucksch (:BenB)]

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

Comment 7

[http://tinymailto.com/oliversl]

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 :-)

Comment 8

[Nick_Jenkins]

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

Comment 9

[Nick_Jenkins]

Attachment: Mock-up screenshot of modifier in bookmark properties.

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).

Comment 10

[Torben]

Shouldn't this live in the URL Bar component?

Comment 11

[Dominik Geisler]

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

Comment 12

[Nick_Jenkins]

For this feature in Firefox, see bug 221161.

Comment 13

[Robin Monks]

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