469140 - Ctrl+Enter in the location bar treats KEYWORDS as incomplete URLs which they aren't (should open keyword's URL in a new tab)

Status: RESOLVED DUPLICATE of bug 237027

(Firefox :: Address Bar, defect)

Description

[Rick Alther]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.4) Gecko/2008102920 (CK-IBM) Firefox/3.0.4
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.4) Gecko/2008102920 (CK-IBM) Firefox/3.0.4

* If I have a bookmark with a keyword, type that keyword and press Ctrl+Enter,
it tries 'www.keyword.com' rather than my bookmarked URL.

IMO Ctrl+Enter should be struck dead or open the URL in another background tab.
 That way the UI is simpler and more consistent.  The user only needs to
remember that 'Ctrl+[click/enter]' opens a link in another tab.  It's much
easier to tell new people "just Ctrl+[click/enter] on any link to open a tab"
than to tell them to remember to use Alt for some and Ctrl for others,
depending on where you are.  That's just an inconsistent UI. I haven't checked
them all, but isn't Firefox the only browser to copy this IE 'feature'?  I
don't recall Opera, Konqueror or Safari doing this (but I don't have them avail
to test ATM). 

Another reason this feature is outdated are the numerous new TLDs out there
(e.g. .biz and .info) as well as the country TLDs.  Firefox is supposed to be
an international browser, yet this feature is inherently US centric.  

If it's decided that this feature should still live, it should take into
account keywords and tags as well.
1) first, it should just check to see if the location is a single word.  If
it's got a '.' in it, it shouldn't even be considered for 'fixing'.
2) Bookmarks should be searched for matching keywords/tags and use the
associated URL if it finds one.
3) Only then should Firefox attempt to 'fix' it.

Reproducible: Always

Steps to Reproduce:
Keyword test
1. Open a bookmark and set a keyword to it.  It's best to set the keyword to something not part of the URL, to avoid confusion.  e.g. don't set a keyword of 'mail' for 'mail.google.com'.
2. Type the keyword in the location bar and press enter to ensure the keyword is working properly.
3. Open a new tab.
4. Type the keyword into the location bar and press Ctrl+Enter.  
Actual Results:  
Notice it prepends 'www' and appends 'com', so the URL takes the form of 'www.keyword.com'.  It does not look up the keyword and use the associated URL as it should.

Expected Results:  
It should search the keywords and go to the associated URL prior to attempting to "fix" the entered URL.

Comment 1

[Rick Alther]

This bug is being submitted as requested from the comments in bug 233853.

Comment 2

[Ria Klaassen (not reading all bugmail)]

Does Alt + Enter do what you want?

Comment 3

[Rick Alther]

Yes, but that's not really the point I was making.  The point is that the UI is inconsistent with the way a user opens a URL/Link in another tab.

For links on pages, you Ctrl+Click/Enter to open in a new tab, but the location bar is different as it uses Alt+Enter.

I don't want to side track the real bug which is that Ctrl+Enter bypases keywords when attempting to 'fix' the URL.  My personal choice is to fix this bug by changing Ctrl+Enter to open the URL in a new tab (you can perserve Alt+Enter).

Since that's not likely, the code needs to check for matching keywords/tags prior to trying to "fixup" the entered text.

See related bugs:
bug 469143
bug 469147

The the original bug that spawned those 3: bug 233853

Comment 5

[Thomas D. (:thomas8)]

This bug covers a subset of Bug 237027 (Inconsistent new tab shortcuts: Alt+Enter in address bar but Ctrl+Enter for links), but based on comment #3 it's not necessarily a duplicate --> confirming, blocks 237027.

Whereas bug 237027 wants to swap alt+enter and ctrl+enter behaviour in location bar altogether, this bug wants the behaviour swapped only/at least for those cases when a user-defined KEYWORD has been entered and user presses ctrl+enter (where keyword is the bookmark property for keyword searches as in "add a keyword for this search" on form fields). This is different from bug 237027 because user deliberately enters a known keyword (i. e. a shortcut for a complete and known URL) and thus treating the keyword as an incomplete url on ctrl+enter is even more unexpected than getting url completions with ctrl+enter in general (which should open the page in a new tab; should use alt+enter for url completion). So this bug adds another good point why bug 237027 should be fixed.

Comment 6

[Thomas D. (:thomas8)]

Also, this bug may be considered as a subset of Bug 469147 (Pressing Ctrl+Enter in the location bar munges valid URLs), because a keyword represents a valid URL which is munged by Ctrl+Enter. But again there are differences so it's not a duplicate. Bug 469147 covers the technical bug, where real existing URLs are incorrectly "completed". This bug is one step before that, and more of a logical bug, where a known keyword (representing a valid URL) is wrongly treated/considered as an incomplete URL.

Comment 7

[Thomas D. (:thomas8)]

On 2nd thoughts (with comment #2 in mind, and building on my comment #5):
Maybe this is a duplicate (/wontfix) candidate, because fixing only a small subset of bug 237027 is likely to add to the current confusion caused by that bug.

@Rick: What if users DO want their existing keyword treated as an incomplete url? Say I have "wp" as a keyword for Wikipedia searches, but this time I want "wp" to be completed into "www.wp.com", which is wordpress? Since we have two modifiers at hand (ctrl vs. alt), this should be possible one way or the other.

I agree with you that it would be best to fix Bug 237027 and swap the modifiers in general (for ui consistency, use ctrl+enter+url in location bar (as with links) to open url in new tab, use alt+enter to complete urls). But unfortunately, that bug isn't fixed yet. So we are looking at the current setting, which is this:

Current behaviour in location bar (due to bug 237027):

1a) ctrl+enter + incomplete_url --> url completion
1b) ctrl+enter + keyword --> url completion (www.keyword.com)
2a) alt+enter + url --> open url in new tab.
2b) alt+enter + keyword [" searchword"] --> open url [search] in new tab
So you CAN use alt+enter + keyword to open keyword url or search in new tab (as per Ria's comment #2, and confirmed by you in comment #3).

(In reply to Rick's comment #2:)
> My personal choice is to fix this bug by changing Ctrl+Enter to open the URL
> in a new tab (you can perserve Alt+Enter).

I understand from this that you are suggesting to fix this bug even if bug 237027 is still standing. What if we would really implement ONLY the changes of this bug? 

Expected behaviour as per this bug (with bug 237027 still standing(!))

1a) ctrl+enter + incomplete_url --> url completion in current tab (bug 237027)
1b)* ctrl+enter + keyword [" searchword"] --> open keyword url [or search] in new tab [expected behviour, this bug]
2a) alt+enter + url --> open url in new tab (bug 237027) 
2b)* alt+enter + keyword --> url completion for keyword in current tab (www.keyword.com) (assuming that users should be able to do this, as I see no reason against this)

I think such a mixture of both will confuse users even more, as we are creating additional competing modifier behaviour /within/ location bar. Currently we "only" have competing modifier behaviour of links etc. vs. location bar. 

On the assumption that it is expected behaviour that users can deliberately use some modifier key to treat an existing keyword as an incomplete url to be completed (--> www.keyword.com), this bug should be marked wontfix or (preferably) duplicate of bug Bug 237027.

Rick (reporter), what do you think?

Comment 8

[Rick Alther]

Without bug 237027 being fixed, I would expect the fix for this bug would not alter the current Alt+Enter behavior.

My suggestion for Ctrl+Enter would be:
1) If text does not contains a single word or a single word followed by a space, check keywords first.  If no keyword matches, go to step 2.
2) Attempt to fixup the URL. (see bug 469147)

However, you bring up a good point in that a keyword may also be the name of a website (wp in your example).  Since keywords are all user created, I would suspect that the user would expect the keyword to take precedence...but then why would the user press Ctrl+Enter?

Since Ctrl+Enter specifically does only one thing at this time ("fix" incomplete URLs which open on the same tab), I would be inclined to say that the user means to fixup whatever text they entered and are explicitly bypassing keywords.

That said, for the existing behavior, this bug should probably be marked 'wontfix' to avoid further confusion.  Fixing bug 237027 and bug 469147 are important to the usability of Firefox.

Regarding "fixing" up of URLs, I'm inclined to think that would be an automatic thing for Firefox, rather than an explicit keystroke.  For example, if I type 'cnn' and press enter, I would expect Firefox to first check keywords.  If no matching keyword is found, then automatically try to fix up the URL (a fixup should only occur if the text enterered contains no periods or spaces).  Not only that, perhaps Firefox goes the extra step in checking various TLDs and presenting a page the user can select from?  e.g. if I type in a word, Firefox might check to see if .com, .net, .org, .info, .biz and .gov sites exist.  If only one exists, go there.  If more than one exists, present a page with all of the links.  Maybe there would be a UI or pref that the user can toggle off any TLDs they don't want searched (or user added TLDs for other countries).

Comment 9

[Thomas D. (:thomas8)]

(In reply to comment #8)
> That said, for the existing behavior, this bug should probably be marked
> 'wontfix' to avoid further confusion.  Fixing bug 237027 and bug 469147 are
> important to the usability of Firefox.

Based on comment #7 and reporter's agreement in comment #8 --> duplicate.
Rick, thanks for your comment. Let's wait until bug 237027 and bug 469147 are fixed and then re-check if keywords are treated correctly.

> My suggestion for Ctrl+Enter would be:
> 1) If text does not contains a single word or a single word followed by a
> space, check keywords first.  If no keyword matches, go to step 2.
> 2) Attempt to fixup the URL. (see bug 469147)

I think you mean
1) If text DOES contain a single word or a single word followed by a
space, check keywords first.  If no keyword matches, go to step 2.

> For example, if I type
> 'cnn' and press enter, I would expect Firefox to first check keywords.  If no
> matching keyword is found, then automatically try to fix up the URL

As long as we have a modifier key for url completion, I think we must treat keywords used with that key as an incomplete url. If url completion would be inbuilt (without modifier), then I think you are right keywords should be checked for first. Inbuilt url completion is a nice idea, but it won't be easy to implement. Personally, I'd prefer more basic stuff to be fixed first, like bug 513064 which makes tagging a web page with existing tags a pain.

Comment 10

[Rick Alther]

(In reply to comment #9)
> > My suggestion for Ctrl+Enter would be:
> > 1) If text does not contains a single word or a single word followed by a
> > space, check keywords first.  If no keyword matches, go to step 2.
> > 2) Attempt to fixup the URL. (see bug 469147)
> 
> I think you mean
> 1) If text DOES contain a single word or a single word followed by a
> space, check keywords first.  If no keyword matches, go to step 2.
Yes, you are correct.  

> > For example, if I type
> > 'cnn' and press enter, I would expect Firefox to first check keywords.  If no
> > matching keyword is found, then automatically try to fix up the URL
> 
> As long as we have a modifier key for url completion, I think we must treat
> keywords used with that key as an incomplete url. If url completion would be
> inbuilt (without modifier), then I think you are right keywords should be
> checked for first. Inbuilt url completion is a nice idea, but it won't be easy
> to implement. Personally, I'd prefer more basic stuff to be fixed first, like
> bug 513064 which makes tagging a web page with existing tags a pain.
> 
> *** This bug has been marked as a duplicate of bug 237027 ***
Agreed.  Personally, I don't care for URL fixup myself and would just rather get rid of it as there are too many potential issues, especially when considering the international aspect.