Closed Bug 233853 Opened 21 years ago Closed 16 years ago

cnn.com, Ctrl+Enter goes to www.cnn.com.com

Categories

(Firefox :: Address Bar, defect)

defect
Not set
normal

Tracking

()

VERIFIED FIXED
Firefox 3 alpha1

People

(Reporter: alther, Assigned: Mardak)

References

Details

Attachments

(1 file, 7 obsolete files)

User-Agent:       
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040207 Firefox/0.8

* Enter 'cnn.com' in the URL field.
* Press CTRL-Enter
* Firefox changes the URL to 'www.cnn.com.com'.  Firefox prepends 'www' and
appends 'com' to whatever URL I type.

This does not happen if I provide a protocol or start the URL with 'www.'

I pressed CTRL-Enter as I'm used to opening links in a background tab in
Mozilla.  I guess Firefox does not yet support opening background tabs.

Reproducible: Always
Steps to Reproduce:
1. Type a URL (sans protocol & 'www') in the URL field. (e.g. cnn.com)
2. Press CTRL-Enter
3. Notice Firefox prepends 'www.' and appends '.com' to whatever URL you entered
without first attempting to connect to the URL provided.

Actual Results:  
Firefox prepends 'www.' and appends '.com' to whatever URL you entered.

Expected Results:  
Firefox should just attempt to connect to the URL as typed.
Noririty fixed this partially in bug 177618.  (Before, Ctrl+Enter would create
URLs like "http://www.http://mozilla.org/.com/"!)

It should be a little smarter and avoid duplicating www. and .com, or maybe only
activate when there are no periods in what's typed.

Btw, use Alt+Enter to open a URL in a new tab, not Ctrl+Enter.
Assignee: bugs → noririty
Summary: CTRL enter on URL field, causes Firefox to generate a bad URL → cnn.com, Ctrl+Enter goes to www.cnn.com.com
Ahhh...Atl+Enter.  May I ask, why the change from Ctrl+Enter that's currently
implemented in Mozilla?  ..and what is Ctrl+Enter supposed to do?
Ctrl+Enter lets you get to ebay by typing ebay and then Ctrl+Enter.  Firebird
uses Ctrl+Enter (rather than another combination) for that feature because IE
uses Ctrl+Enter.
It's supposed to pretend to be IE and prepend http://www. and append .com so
that you can enter, say, just for example, "microsoft" in the url bar and it
goes to http://www.microsoft.com

If you build your own you can apply a patch to change where it goes as
mentionned in bug 221161.

As you might be able to tell, I've never liked this whole IE ctrl+enter thing.
Created a bunch of needless bugs like this one. Which I'm confirming since we're
already knee-deep in muck we might as well go the whole way.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Not to start a war or anything, but Ctrl+Enter makes a lot more sense to me to
open a URL in a tab.  You Ctrl+Click to open a link in a tab?  What about
Ctrl+Enter on a link that has focus in the page? (I don't have Firefox in front
of me to test right now.)  To me, Ctrl+[link/URL] means open in a tab.  Now I
have to remember Ctrl for some actions and Alt for others.  Also, Alt+Enter is a
'more difficult' key combo to hit as Alt is more toward the center of the
keyboard and you now have to jump over the 'Windows' key (if you have your hands
in the standard typing position.)

If Ctrl+Enter is soleley to let users do shortcuts (e.g. type 'ebay' and the
browser will automatically go to 'www.ebay.com'), then I think it's the wrong
approach.  Mozilla/Firefox should try the shortcut if there are no dots in the
URL regardless of the key combo used. 

What would happen if I had a bookmark associated with a keyword 'ebay'?  What
would happen then if I typed 'ebay' and then Ctrl+Enter?  I would hope my
keyword would override the 'smart' Firefox code and not try 'www.ebay.com'.

In summary:
* Opening links in another tab should be consistent across the interface, and
that means using a single modifier key: Ctrl.  Having to remember when you need
to use Ctrl or Alt is just plain bad UI design.

* Firefox should never try to correct my URL unless:
a) I have the option selected in the preferences ('Domain Guessing' in Mozilla).
b) Only change the URL if there are no dot separators.

* Finally: just because it's in IE doesn't mean we should copy it.  Improve the
good, bury the bad from IE.

Am I oversimplifying the issues here?
see also the other canonizeUrl bugs:
bug 218447
bug 233205
bug 233313

I think that we should not be reimplementing nsDefaultURIFixup in javascript at
all.  Instead, we should use createFixupURI(uri,FIXUP_FLAGS_MAKE_ALTERNATE_URI);
to do the job properly.  (and if it doesn't provide all the features, add them in.)

(If ctrl-enter, shift-enter, and ctrl-shift-enter all disappeared I would be
happy too.)
*** Bug 240799 has been marked as a duplicate of this bug. ***
*** Bug 243332 has been marked as a duplicate of this bug. ***
*** Bug 240799 has been marked as a duplicate of this bug. ***
Ok, this patch fixes a number of things.

If a url already has any of www. , http, / , .com , .org or .net, the
Ctrl+Enter feature will do nothing.

Finally, if someone has typed in something like mozilla/products/firefox and
presses Ctrl+Shift+Enter it will head to www.mozilla.org. Ideally it would go
to www.mozilla.org/products/firefox but I can't seem to get it to (Daniel:
since you created that part of the patch can you check it? What I added should
not have had an effect on what you already had, so I'm not sure if your
original actually worked the way it was intended...)
Assignee: noririty → davidpjames
Status: NEW → ASSIGNED
(In reply to comment #10)
> Ideally it would go
> to www.mozilla.org/products/firefox but I can't seem to get it to (Daniel:
> since you created that part of the patch can you check it? What I added should
> not have had an effect on what you already had, so I'm not sure if your
> original actually worked the way it was intended...)

I'm checking it now.
Mike or Ben: can one of you look at this and decide whether we want this in for
0.9 or 1.0?

Thanks
Blocks: 233313
Attached patch Fixes some details in the fix (obsolete) — Splinter Review
Fixed it.
Actually, the problem was quite simple: the "/" test didn't make sense anymore
with my suggestion.
However, it used to be a test for "\/\s*$" (URL ending in "/" and with possibly
some whitespace), so it wouldn't skip "mozilla/products", only with "mozilla/".
The last patch changed that part of the regexp to:
    \/|\.com|\.org|\.net\s*$
Note the "\s*$", which should be kept after \/, now applied to the .net suffix.
I removed both the / part and the \s*$ that was with the .net.

Also on this patch: fixed indentation on my code (sorry) and removed "prefix"
variable, as suggested by David (bug 240799 comment #11)
Comment on attachment 148276 [details] [diff] [review]
Fixes some details in the fix

(In reply to comment #13)
> Fixed it.
> Actually, the problem was quite simple: the "/" test didn't make sense anymore
> with my suggestion.
> However, it used to be a test for "\/\s*$" (URL ending in "/" and with possibly
> some whitespace), so it wouldn't skip "mozilla/products", only with "mozilla/".
> The last patch changed that part of the regexp to:
>     \/|\.com|\.org|\.net\s*$
> Note the "\s*$", which should be kept after \/, now applied to the .net suffix.

Ah, oops.

> I removed both the / part and the \s*$ that was with the .net.

Ok... That was added in bug 177618 and your patch still manages to achieve the
intention of what was done before (trailing spaces following a '/' are dealt
with). A trailing space on a single word is still a problem, but that problem
is not new (type 'mozilla ' then Ctrl+Shift+Enter will give an error, before
and after the patch).

Looks good to me. Mike?
Attachment #148276 - Flags: review?(mconnor)
I was just rereading the comments to this bug and came across Jesse's point in 
comment #1 about not activating if there are periods... that would cover cases 
for int'l and other endings like .ca, .co.uk, .info etc. 
 
It would also simplify things a bit: 
Instead of: 
if (!/^(www\.|http)|\.com|\.org|\.net/i.test(url)) { 
we might be able to get away with 
if (!/^(http)|\./i.test(url)) { 
 
But it would rule out tacking on stuff to a typed url like aaa.bbb which is 
supposed to be www.aaa.bbb.com. The only examples of this I can think of so 
far are from my old university, Queen's - www.econ.queensu.ca for example, but 
since it is .ca it doesn't apply.

So now we have two choices of behaviour - look for www., http, .com, .org, .net
or look for http or a period in the url to disable Ctrl+Enter etc.
Attachment #148273 - Attachment is obsolete: true
I was writing this one while David made his attachment.
The idea was to deal with the whitespace (it just trails any whitespace before
and after the typed URL.

Also, I am using this slightly-enhanced expression:
  /^(www\.|http:)|^[^\/]*\.(com|org|net)\b/i
Made it to check for suffixes only before any slash.

I'm also making a period version of this patch (because of the whitespace fix)
Attachment #148276 - Attachment is obsolete: true
I don't know JS so I don't want to screw it up, but it might be better to search for

:

in the address rather than http. That way if a domain starts with
http<something> then you can still do a CTRL-Enter on it. Plus, this would also
take care of ftp:// (and still take care of https://)

Also I don't want to be anal about it, but I'd like to point out that we also
have there is a domain named com.com but of course you do what you like with this ;)
Here's the alternative version.

By the way, I'm using this expression:
  /^http:|^[^\/]*\./i
It checks for periods only before any slash, and looks for "http:" (for the
same reason we're checking for "www." instead of "www")
Forgot we were looking for starting strings. Then maybe add:
ftp:

and

https:

?
I've said it before and I'll say it again even though it will fall on deaf ears.

Why are we changing the behavior of CTRL+Enter from the way Mozilla does it? 
Mozilla does it right, so why are we breaking something that already works and
is intuitive?

Different ways of opening links/URLs in a separate tab:
* Ctrl+click
* Ctrl+Enter (if focus is on a link)
Mozilla: Ctrl+Enter (if on address bar) - Consistent with other methods.
Firefox: Alt+Enter  (if on address bar) - Inconsistent with other methods.

That's just bad UI design and it's inconsistent across the interface.  In
Mozilla, I know I can Ctrl+(Click/Enter) and it'll open another tab.  With
Firefox, it's just a mess.  I have to remember a different key combination to do
the same thing depending on where the focus is?  Please.  At the very least,
allow this feature to be turned off via Preferences.

If anyone agrees with me on this, please speak up.  Am I the only one who thinks
this?
I agree with Phong... so I changed my expression to:
  /^www\.|^[^\/]*(:|\.(com|org|net)\b)/i

There are cases like www.website.com:port, but I think we're getting a little
out of scope here.
I'm not sending another patch atm, as we already had 3 in the last couple
minutes. So I'm waiting to see if anyone comes with more changes.

Rick: as Firefox targets to be a Windows browser, it's offering features Windows
users are used to (from IE). I do agree with you on offering an option, though.
(In reply to comment #20)

> If anyone agrees with me on this, please speak up.  Am I the only one who thinks
> this?

I was thinking of this just now... since we've now managed to come up with a way
of disabling Ctrl+Enter appending behaviour in all the cases where in Mozilla
someone might have used Ctrl+Enter to open in a new tab it may be possible to go
ahead and open that in a new tab.

Example:
(1) if I type 'cnn', then press Ctrl+Enter it does the IE thing.
(2) if I type 'mozilla.org' then press Ctrl+Enter we'll simply load that url in
the current tab with any of the patches that have been submitted so far. It
should be possible to make that open in a new tab instead somehow... anyone got
any ideas on how to make that happen, because I'd really like to see that in
Firefox (consistent with Mozilla and Konqueror and who knows what else).

Basically, only words should be subject to the IE thing. URLs should do what
Mozilla has always done.
(In reply to comment #21)
> Rick: as Firefox targets to be a Windows browser, it's offering features Windows
> users are used to (from IE). I do agree with you on offering an option, though.
Since when has the Mozilla project started targeting Windows only?  I thought
the Mozilla project was to create the best cross platform, standards compliant
browser, with cutting edge technology.  

I'm sorry, but I don't want Windows/IE quirks appearing in my Linux or Mac OS
browser simply because we want to appease Windows users.  Let them learn a
better way to browse rather than bring over bad carrot & stick features that
don't fit well into Firefox.  To me it seems you're trying to fix a square peg
into a round hole.  Everyone I introduce to Mozilla, without fail, loves it and
can't imagine going back to IE.

Besides, Mozilla already does domain guessing WITHOUT a key combination, which
is the correct thing to do...AND I can turn it off in the preferences.  I don't
need a key combo to activate it.  Mozilla just does the right thing.  Why
doesn't Firefox just do the same thing that Mozilla already does correctly?  Why
fix what is not broken?

I'm sorry if this sounds like a rant, but I am fearful of IE feature creep into
Mozilla/Firefox.  IE is not that great of a browser regardless of how many
people use it, so why bring Mozilla/Firefox down to its level by incorporating
bad ideas from IE?
(In reply to comment #23)

I think it's a great idea because:
1) Then I can use my location bar as a Google search bar without using keywords
and such
2) Domain name guessing is slower
3) Domain name guessing does not provide the granularity of choosing between
different extensions yourself (.net, .com, .org) for the same domain.
> Since when has the Mozilla project started targeting Windows only?  I thought
> the Mozilla project was to create the best cross platform, standards compliant
> browser, with cutting edge technology.  

You're right about the Mozilla project... but Firefox is not the only project of
the Mozilla foundation, nor the main one (for now) :)

From http://www.mozilla.org/projects/firefox/charter.html :
"Firefox grew out of the desire to make the best browser for Microsoft Windows.
Eventually we began to build on Linux as well, and also Macintosh. Most of our
development work is done on Windows, and so that platform naturally tends to
lead although we express a desire to work as well as is feasible on every system
we can. Today, our goal is to be the best browsing solution on Windows and
Linux, while at the same time striving to improve our functionality on MacOS X
in order to be competitive."

I see your point, but I do use this ctrl+enter (and others) feature (and
actually I didn't use it yet in my IE days), and I'm not the only one here who
likes it.

Again, I fully support adding an option for that. I'll see if I can do that
myself (I'm not used to messing with the Mozilla source, but as it seems to be
purely a Javascript/XUL issue I don't need to recompile the browser, saving me a
lot of trouble). If so, I'll file a new bug and mention it here.
(In reply to comment #24)
> (In reply to comment #23)
> 
> I think it's a great idea because:
> 1) Then I can use my location bar as a Google search bar without using keywords
> and such
I can already use the location bar in Mozilla to directly search Google. 
Firefox also changed this behavior, which I really dislike.  

> 2) Domain name guessing is slower
Agreed, but doesn't it usually get it right?  Personally, if I end up going to a
site often enough, it's in my Autocomplete cache, so it's not an issue.

> 3) Domain name guessing does not provide the granularity of choosing between
> different extensions yourself (.net, .com, .org) for the same domain.
OK, but what about .gov, or .mil or any of the country TLDs?  Or what about any
of the dozens of new TLDs that will appear (like .info, or .tv?)  If the user
could enter in what TLDs they want to have in the preferences, that would be
great.  

What happens if a site name exists in two or more TLDs?  e.g. mysite.com and
mysite.org?  Which one will it go to?  What if it goes to the wrong one all the
time, how do I, as a user, fix that?

Maybe I'm not clear on EXACTLY how this will work other than my poor experience
with it that prompted me to open the bug in the first place.

My primary beef with this whole thing is the changing of the behavior of the
CTRL+Enter key combo from opening a new tab to performing this new type of
behavior.  Why can't this be done automatically without changing the behavior of
the key combo?  Or make Alt+Enter the key combo (AFAIK, it's not currently
assigned to anything in Mozilla).
(In reply to comment #25)
> > Since when has the Mozilla project started targeting Windows only?  I thought
> > the Mozilla project was to create the best cross platform, standards compliant
> > browser, with cutting edge technology.  
> 
> You're right about the Mozilla project... but Firefox is not the only project of
> the Mozilla foundation, nor the main one (for now) :)
> 
> From http://www.mozilla.org/projects/firefox/charter.html :
> "Firefox grew out of the desire to make the best browser for Microsoft Windows.
> Eventually we began to build on Linux as well, and also Macintosh. Most of our
> development work is done on Windows, and so that platform naturally tends to
> lead although we express a desire to work as well as is feasible on every system
> we can. Today, our goal is to be the best browsing solution on Windows and
> Linux, while at the same time striving to improve our functionality on MacOS X
> in order to be competitive."
Ah, OK.  But I was under the impression that Firefox and Thunderbird were the
future direction of the Mozilla project, i.e. it would supersede the current
Mozilla project at some point.  If that's the case then I would expect these
projects to proceed with the same platform neutral direction that Mozilla
currently does.

> I see your point, but I do use this ctrl+enter (and others) feature (and
> actually I didn't use it yet in my IE days), and I'm not the only one here who
> likes it.
I'm not saying the feature itself is bad, but that the UI is inconsistent and
diverges from the current Mozilla usage (which IMO, is correct and is UI
consistent).
 
(In reply to comment #26)
> I can already use the location bar in Mozilla to directly search Google. 
> Firefox also changed this behavior, which I really dislike.  

How does Mozilla do a Google search on a word if it's going to do domain name
guessing on it?

> > 2) Domain name guessing is slower
> Agreed, but doesn't it usually get it right?  Personally, if I end up going to a
> site often enough, it's in my Autocomplete cache, so it's not an issue.

The fact that it gets it right or not is not my issue here. It's that I have to
wait for it to complete it.

> > 3) Domain name guessing does not provide the granularity of choosing between
> > different extensions yourself (.net, .com, .org) for the same domain.
> OK, but what about .gov, or .mil or any of the country TLDs?  Or what about any
> of the dozens of new TLDs that will appear (like .info, or .tv?)  If the user
> could enter in what TLDs they want to have in the preferences, that would be
> great.  

Currently they can using about:config, although it would probably be a good idea
to make a UI for it in Options.

> What happens if a site name exists in two or more TLDs?  e.g. mysite.com and
> mysite.org?  Which one will it go to?  What if it goes to the wrong one all the
> time, how do I, as a user, fix that?

Hm... I'm having problems understanding the issue here. With CTRL-Enter,
Shift-Enter, and CTRL-Shift-Enter you get to pick the extension.
Sounds to me this would be an issue with domain name guessing, not CTRL-Enter.

> My primary beef with this whole thing is the changing of the behavior of the
> CTRL+Enter key combo from opening a new tab to performing this new type of
> behavior.  Why can't this be done automatically without changing the behavior of
> the key combo?  Or make Alt+Enter the key combo (AFAIK, it's not currently
> assigned to anything in Mozilla).

So do we want to mess with current users of Firefox (because ALT-Enter opens in
a new tab in Firefox), or with potential users who are currently using Mozilla?
I agree that consistency is a good thing, but that's the kind of choice that
needs to be made early on; switching so close to release just for the sake of
being consistent with *another product* is not entirely reasonable (IMO anyway).
(In reply to comment #28)
> (In reply to comment #26)
> > I can already use the location bar in Mozilla to directly search Google. 
> > Firefox also changed this behavior, which I really dislike.  
> 
> How does Mozilla do a Google search on a word if it's going to do domain name
> guessing on it?
I type in my search term in the location bar, down arrow to select the "Search
Google for" option and hit Ctrl+Enter to open the search results in a new tab. 
Much quicker and easier than the current Firefox implementation of a separate
search bar (IMO).

> > > 2) Domain name guessing is slower
> > Agreed, but doesn't it usually get it right?  Personally, if I end up going to a
> > site often enough, it's in my Autocomplete cache, so it's not an issue.
> 
> The fact that it gets it right or not is not my issue here. It's that I have to
> wait for it to complete it.
True.

> > What happens if a site name exists in two or more TLDs?  e.g. mysite.com and
> > mysite.org?  Which one will it go to?  What if it goes to the wrong one all the
> > time, how do I, as a user, fix that?
> 
> Hm... I'm having problems understanding the issue here. With CTRL-Enter,
> Shift-Enter, and CTRL-Shift-Enter you get to pick the extension.
> Sounds to me this would be an issue with domain name guessing, not CTRL-Enter.
OK, but I have to remember all these different [mod-key]-Enter combos and what
TLD they go to.  I suppose you get used to it after a while, but it's still very
limiting.  You can only choose 3 different TLDs.  What about all the other TLDs?
  
> > My primary beef with this whole thing is the changing of the behavior of the
> > CTRL+Enter key combo from opening a new tab to performing this new type of
> > behavior.  Why can't this be done automatically without changing the behavior of
> > the key combo?  Or make Alt+Enter the key combo (AFAIK, it's not currently
> > assigned to anything in Mozilla).
> 
> So do we want to mess with current users of Firefox (because ALT-Enter opens in
> a new tab in Firefox), or with potential users who are currently using Mozilla?
No, Firefox should aim for UI consistency.  This is just confusing.


> I agree that consistency is a good thing, but that's the kind of choice that
> needs to be made early on; switching so close to release just for the sake of
> being consistent with *another product* is not entirely reasonable (IMO anyway).
It's not just being consistent with another product, you're going from UI
consistency (since Firefox is based off of Mozilla), to inconsistent UI for the
sake of being like IE, which is just a plain bad UI to mimic.  You're grouping
Firefox users into the same set as IE users.

When users move from IE to Mozilla, the browsing experience is so much more that
they don't mind learning how tabbed browsing works.  The only thing you have to
tell them is Ctrl+Click/Enter will open the link/URL in another tab.  To them,
tabbed browsing is very simple.  Since users coming from IE have to learn a new
browser anyway, why not make it UI friendly as well.  Now it's complex.  No
simple rule to remember.  Bad UI.

Also, assuming Firefox will ultimately be the successor to Mozilla, you're
alienating the established Mozilla user base (relatively small as it may be, but
always growing).  To me Firefox IS Mozilla, but the next generation.  I expect
it to behave very similarly, but not necessarily exactly the same.  Mozilla
isn't perfect, but we should always be striving to make the UI more intuitive
and simple.  That means not changing the good, and replacing the bad with the
good, even if it means minor inconvenience, because if it's really better,
people will adapt to it quickly.  Tabbed browsing is one of the primary reasons
people switch and it's one of the features people use the most.  The Mozilla UI
is good for this, why break it?

Is this horse dead yet? ;-)
Attachment #148276 - Flags: review?(mconnor)
when did this bug become the "state of the location bar" great debate? anyway,
I'll deal with the various arguments before I even look at the patch.

last I heard, based on downloads, we have more users of Firefox 0.8 than Mozilla
Suite 1.6, so breaking a long-established Fx shortcut to match Mozilla is
actually going to negatively affect more users than it affects positively. 
Personally, I like alt-enter better since I have to move my hand less to use it.
 In a year it'll be largely irrelevant since it'll then be established.

Making Ctrl-Enter subjectively open in new tabs is not a good idea, either,
since that makes the shortcut do multiple things depending on context, which can
certainly create user confusion.  So that's just a no-go, out of the box.

As for domain name guessing vs. IK, that's yet another discussion.  Domain
guessing is often useless these days with the proliferation of new TLDs and of
course, domain squatting.

Finally, how is type, downarrow, Ctrl-Enter any better/worse than tab, type,
alt-enter? its the same amount of keystrokes, and the latter actualy involves
less hand movement (thereby being "faster" in some UI measurement metrics)

as for the point of THIS bug, namely better parsing during the domain
completion, I'll look at the patch later this weekend. :)
(In reply to comment #30) 
> last I heard, based on downloads, we have more users of Firefox 0.8 than 
Mozilla 
> Suite 1.6, so breaking a long-established Fx shortcut to match Mozilla is 
> actually going to negatively affect more users than it affects positively.  
> Personally, I like alt-enter better since I have to move my hand less to use 
it. 
>  In a year it'll be largely irrelevant since it'll then be established. 
 
I'm not proposing to break Alt+Enter. That bad decision is here to stay 
unfortunately. But this won't negatively affect any Fx user used to Alt+Enter, 
or even IE's Ctrl+Enter for that matter. What it will do is make Mozilla users 
happy and maintain compatibility with Mozilla and Konqueror. 
 
>  
> Making Ctrl-Enter subjectively open in new tabs is not a good idea, either, 
> since that makes the shortcut do multiple things depending on context, which 
can 
> certainly create user confusion.  So that's just a no-go, out of the box. 
 
Don't give me that BS Mike. User confusion? We have that right now with 
Ctrl+Enter anyway (even excluding ex-Mozilla, there's still the 
Ctrl+Enter/Left-Click on links but not in the url bar). Shortcuts doing 
multiple things? We have that right now with Enter and Go - copy this sentence 
into the bar and hit Enter. It does something different than if you copied 
mozilla.org and hit Enter. Ctrl+I does different things depending on whether 
you're using a Linux version or a Windows version of Firefox. If you're going 
to argue against it use an argument that isn't so clearly full of holes. Heck, 
all of the patches and what we do right now all violate this premise - if what 
a user has typed includes www or http or ends in / we disable IE Ctrl+Enter. 
The next logical step is to disable IE Ctrl+Enter on anything that looks like 
a url. Once you've done that you might as well just go ahead and open it in a 
new tab, *since that's probably what they were expecting anyway*. 
 
You have to analyze the circumstances under which a former IE user would be 
using Ctrl+Enter - they're going to use it on words - 'cnn', 'hotmail' etc. 
They are not going to use it on things that look like a url - 'cnn.com', 
'www.hotmail.com', 'http://www.mozilla.org/products/firefox/' etc because in 
IE that will result in the same dumb behaviour that we more-or-less do right 
now - add www. and .com and send the user off to some non-existent url 
(there's some bona fide user confusion, btw). So the only ones who are going 
to do it under those circumstances are former Mozilla users and people who 
know about the short-cut. It's a no-brainer really. It won't affect former IE 
users but will make former Mozilla users happy. No one is negatively affected 
but some people are positively affected - a Pareto superior change :) 
 
Here's an idea - give it a try and see how many bug reports that it generates. 
I'll know since I'll get to see them, but I doubt I will. It certainly can't 
create anywhere near as much user confusion as the current Enter and Google 
"I'm feeling lucky" behaviour generates. 
 
 
> Finally, how is type, downarrow, Ctrl-Enter any better/worse than tab, type, 
> alt-enter? its the same amount of keystrokes, and the latter actualy 
involves 
> less hand movement (thereby being "faster" in some UI measurement metrics) 
 
Because Ctrl is in a corner and is easier to hit without looking, especially 
with one's left little finger. That's probably why most of the other shortcuts 
employ Ctrl and not Alt. 
alt isn't any harder to hit without looking, the home position in touch typing
is an inch away.  The reason that Ctrl isn't used more is because starting with
DOS apps and continuing through win3.1 and forward, , Alt was used as a trigger
for accesskeys,  so shortcuts took ctrl.  I hit Alt-enter way faster than I ever
hit Ctrl-Enter using Moz.

existence of a stupid inconsistency is not justification for more, btw :)  I
think I actually own the bug that's discussing that one 

as for doing it and seeing what happens, maybe after 1.0 :)
alt-enter is supposed to mean properties on windows. that said, do you use the
left alt key or the right alt key? if you use the right alt key, then does
altgr-enter do the same thing as alt-enter? if you do, and it doesn't, then
you're relying on something that won't work on some systems.
I've just tried and ALTGr-Enter does nothing. I doubt that anyone would use
ALTGr-Enter. This is merely an opinion and in no way based on statistics however.
I don't get it.  How do you people keep straight in your heads that it's
ctrl-click, but alt-enter, to open in a new tab?  Even for people who haven't
been using ctrl-enter for years in mozilla, "add control to open in a new tab"
is a consistent rule; "add control to some actions and alt to others" is
inconsistent and therefore bad UI.

Firefox is deliberately shipping bad UI just to copy a product from a company
famous for bad UI.  Copying what's bad about the competition isn't the way to
beat them.
Attached patch Patch against more recent code (obsolete) — Splinter Review
I know the bug reporter has an issue with ctrl-enter and alt-enter, but other
bugs have been marked as a duplicate of this one such as being able to
ctrl-shift-enter mozilla/projects/firefox to get
http://www.mozilla.org/projects/firefox, so hopefully this can make it in to
1.5.

I've updated the patch against a more recent browser.js, and changed how it
picks apart which part to add the suffix, but it should work the same. I could
file another patch if the slash_index method is preferred.

I left the / in the suffix because there's existing code to add on a / if
browser.fixup.alternate.suffix did not have it; otherwise, it would require
extra code to remove the / if it did exist.
Assignee: davidpjames → nobody
Status: ASSIGNED → NEW
OS: Linux → All
QA Contact: davidpjames → location.bar
Hardware: PC → All
Is Eddie still working on this? A year, come on!
Updated patch against newer code (bug 279035 fixed) and with new logic - figure out if the suffix that we're trying to add is already in the url and act accordingly while avoiding false positives. The position of the slash and suffix should never be in the same place unless the suffix is set by the user to be "/...".

* Logic for slash and existing suffix (example)
No slash, no suffix: Add suffix (mozilla)
No slash, yes suffix: Add slash (mozilla.com)
Yes slash, no suffix: Insert suffix (mozilla/stuff)
Yes slash, suffix before slash: Do nothing (mozilla.com/stuff)
Yes slash, suffix after slash: Insert suffix (mozilla/?stuff=.com)

The last case is to still add a suffix even if it shows up somewhere in the url after the first slash. "squarefree/?s=.com" ctrl-enter correctly searches for .com on www.squarefree.com instead of ending up at www.squarefree/?s=.com
Attachment #192158 - Attachment is obsolete: true
Attachment #240108 - Flags: review?(gavin.sharp)
Comment on attachment 240108 [details] [diff] [review]
Check to-be-added-suffix before adding suffix

>Index: ./browser/base/content/browser.js

>+      if (firstSlash >= 0) {
>+        if (existingSuffix == -1 || existingSuffix > firstSlash)
>+          url = url.substring(0, firstSlash) + suffix +
>+                url.substring(firstSlash + 1, url.length);

You can omit the "url.length" parameter here. r=me with that, thanks for the comments!
Attachment #240108 - Flags: review?(gavin.sharp) → review+
Assignee: nobody → edilee
Target Milestone: --- → Firefox 3 alpha1
Version: unspecified → Trunk
Whiteboard: [checkin needed]
Omitted url.length.

37c37
< +                url.substring(firstSlash + 1, url.length);
---
> +                url.substring(firstSlash + 1);
Attachment #240108 - Attachment is obsolete: true
Attachment #242235 - Flags: review?(gavin.sharp)
Comment on attachment 242235 [details] [diff] [review]
Check to-be-added-suffix before adding suffix v2

No need to re-request review, I already marked it + :)
Attachment #242235 - Flags: review?(gavin.sharp)
Attachment #148309 - Attachment is obsolete: true
Attachment #148307 - Attachment is obsolete: true
Attachment #148306 - Attachment is obsolete: true
mozilla/browser/base/content/browser.js 	1.722
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
Whiteboard: [checkin needed]
Verified fixed in Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1a2pre) Gecko/20080819020844 Minefield/3.1a2pre
Status: RESOLVED → VERIFIED
This bug is NOT fixed.

* If I type 'acm.org' and Ctrl+Enter, it goes to the wrong address - it tries 'www.acm.org.com'.
* 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.
* The same behavior applies to bookmarks that have tags associated withe them and I type the tag and press Ctrl+Enter.  It goes to 'www.tag.com' rather than the associated 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.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
I should say it's not fixed as of Firefox 3.0.1.  I did not test the alpha.
I merely tested cnn.com as stated in comment #0, but not others.
(In reply to comment #44)
> This bug is NOT fixed.

Rick, could you please file a new bug on those other cases (and CC me)? Trying to track multiple fixes in one place just leads to trouble.
Status: REOPENED → RESOLVED
Closed: 18 years ago16 years ago
Resolution: --- → FIXED
Status: RESOLVED → VERIFIED
Any progress on those other cases? Got a bug number?
Sorry for the rather large delay in getting those bugs submitted, but I've finally submitted them.  I have broke them up into 3 separate bugs, but the tags and keywords bugs are likely the same thing.
Here are the bug numbers:
bug 469140
bug 469143
bug 469147
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: