Closed Bug 220589 Opened 21 years ago Closed 20 years ago

Cmd-Enter and Cmd-Shift-Enter should work like win/lin builds

Categories

(Firefox :: Keyboard Navigation, defect)

PowerPC
macOS
defect
Not set
major

Tracking

()

RESOLVED FIXED
Firefox1.5

People

(Reporter: aaron, Assigned: asaf)

References

Details

Attachments

(1 file, 2 obsolete files)

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.6a) Gecko/20030926 Firebird/0.7+/jtalkington-nightly
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.6a) Gecko/20030926 Firebird/0.7+/jtalkington-nightly

Ctrl-Enter should autocomplete www.[location text].com and Ctrl-Shift-Enter to
autocomplete www.[location text].org. This works on the Windows/Linux
versions... one would expect the Mac version to work similarly.

Reproducible: Always

Steps to Reproduce:
1. Hit one of the above key combinations.
Actual Results:  
Nothing.

Expected Results:  
Prepend 'www.', append '.com' or '.org' then go.
Confirming for
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5) Gecko/20030926
Firebird/0.7
(This is the RC build)
It was also the same for the jtalkington nightly I was using, 20030928.

I don't have any actual powers though, so I can't mark as new or verified or
anything.

I find this bug really annoying after using the PC version for about a year. I
would say this is a bug, not an enhancement, as this works in other operating
systems.
confirming RFE
Assignee: blake → hyatt
Status: UNCONFIRMED → NEW
Ever confirmed: true
QA Contact: mpconnor
David Hyatt is no more active in the project BUG should be reassigned
Assignee: hyatt → bugs
Flags: blocking1.0mac?
The appropriate Mac shortcuts should be Cmd-Enter and Cmd-Shift-Enter, both of
which work for me.  Firefox 0.9.1 on OS X 10.3.4.
> The appropriate Mac shortcuts should be Cmd-Enter and Cmd-Shift-Enter, both of
which work for me.  Firefox 0.9.1 on OS X 10.3.4.

The use of Cmd instead of Ctrl can be argued, I'm not really sure what it should
be. Since this is originally an IE/Win feature, there is no Mac equivalent. In
IE/Mac, Cmd+Enter opens the link in a new window, ctrl+enter is ignored. In
Safari, Cmd+Enter opens the link in a new tab or window, depending on if you
have tab browsing enabled.

Secondly, I just tested under the exact same configuration and got nothing.
- Cmd+enter showed no completion, and did google "I'm feeling lucky" completion.
Try testing it with "mozilla"; it sent me to www.mozilla.org, not www.mozilla.com.
- Cmd+shift+enter ignored the Cmd and did the equivalent of Shift+enter, which
sends you to www.mozilla.net. It should've gone to www.mozilla.org.
Component: General → Keyboard Navigation
Summary: Ctrl-Enter and Ctrl-Shift-Enter should work like win/lin builds → Cmd-Enter and Cmd-Shift-Enter should work like win/lin builds
*** Bug 263757 has been marked as a duplicate of this bug. ***
*** Bug 263764 has been marked as a duplicate of this bug. ***
*** Bug 264719 has been marked as a duplicate of this bug. ***
*** Bug 268708 has been marked as a duplicate of this bug. ***
Should this be listed as an enhancement?  It seems like basic functionality to
me, particularly as we are led to assume that Firefox has cross-platform
compatibility and feature-parity.

On an additional note, I can verify this bug with:
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.5) Gecko/20041107
Firefox/1.0
Flags: blocking-aviary1.0mac?
This bug should be marked as Normal severity.

I also think it should be targeted for 1.1, since it does hurt Mac builds'
usability and feature-parity.
It is an enhancement.  The lack of a feature on a certain platform is not a bug,
unless its supposed to be there.  It was obviously excluded for a reason,
whether that reason is still valid I don't know.
By the way, its currently listed in the Mac shortcut list.
(In reply to comment #12)
> It is an enhancement.  The lack of a feature on a certain platform is not a bug,
> unless its supposed to be there.  It was obviously excluded for a reason,
> whether that reason is still valid I don't know.

Does anyone know what this reason is/was?  If not, does anyone know who might
know?  It seems absurd to disable this feature on Mac out of some weird
traditionalism.
> It is an enhancement.  The lack of a feature on a certain platform is not a bug,
> unless its supposed to be there.  It was obviously excluded for a reason,
> whether that reason is still valid I don't know.

Actually, it's a bug. The functionality is currently there, but the keymappings
got set wrong. If you type in a search term in the search box and hit
Option-Enter, it will act like Cmd-Enter should. Same thing goes for entering an
address in the address bar, but Cmd-Clicking on a link works as expected
(opening the link in a new tab). This bug is very annoying because of the
inconsistencies.

Hope this info helps.
(In reply to comment #13)
> By the way, its currently listed in the Mac shortcut list.

Hm, just checked now at http://www.mozilla.org/support/firefox/keyboard and it's
not. Only the .net completion (which works as advertised) is listed.

(In reply to comment #15)
> If you type in a search term in the search box and hit
> Option-Enter, it will act like Cmd-Enter should. Same thing goes for entering an
> address in the address bar, but Cmd-Clicking on a link works as expected
> (opening the link in a new tab).

Not sure what you mean here... using 1.0 I still get the same behavior described
in Comment #5. What version are you running?
(In reply to comment #16)
> Hm, just checked now at http://www.mozilla.org/support/firefox/keyboard and it's
> not. Only the .net completion (which works as advertised) is listed.

This was changed three weeks ago due to bug 268749.  This sort of circular logic
is very counterproductive: we can't remove features from the documentation
because they're not implemented and then not implement features because they're
no longer in the documentation.

The question remains as to why CMD-Enter and CMD-Shift-Enter can't be mapped to
the autocompletes.  As Kipp pointed out, it's ridiculous to have half of the key
mappings.  In particular, having Shift-Enter autocomplete but not the other two
seems bizarre to me.

Please note that this is not an appeal to have the remaining keyboard shortcuts
removed.
Flags: blocking-aviary1.1?
(In reply to comment #12)
> It is an enhancement.  The lack of a feature on a certain platform is not a bug,
> unless its supposed to be there.  It was obviously excluded for a reason,
> whether that reason is still valid I don't know.

mconnor: the reason it doesn't work is way different. Our mac event code doesn't
prevent things like *control*+enter/control+modifier+enter on mac (becuase
various reasons) and the code in canonizeUrl isn't #ifdefed to handle the
meta-key (which is the accel/command key on mac) instead of control. Note that
shift+enter is already working...
Severity: enhancement → major
Attached patch patch v1 (obsolete) — Splinter Review
cleanup spaghetti code
Assignee: bugs → bugs.mano
Status: NEW → ASSIGNED
Attachment #173461 - Flags: review?(mconnor)
Target Milestone: --- → Firefox1.1
Attached patch v1.1 (obsolete) — Splinter Review
|if (suffix != null)| has always happend -> moving |aTriggeringEvent|
null-check to |accelPressed| and |shiftPressed|
Attachment #173461 - Attachment is obsolete: true
Attachment #173486 - Flags: review?(mconnor)
Attachment #173461 - Flags: review?(mconnor)
Blocks: macmeta
Comment on attachment 173486 [details] [diff] [review]
v1.1

lets not make this confusing, accelPressed and shiftPressed should be vars,
since they're going to be different a lot of the time.
Attachment #173486 - Flags: review?(mconnor) → review-
(In reply to comment #20)
> Created an attachment (id=173486) [edit]
> v1.1
> 
> |if (suffix != null)| has always happend -> moving |aTriggeringEvent|
> null-check to |accelPressed| and |shiftPressed|

well, this one was wrong if there is no TriggeringEvent, the suffix would be null.
Attached patch v1.2Splinter Review
Attachment #173486 - Attachment is obsolete: true
Attachment #173519 - Flags: review?(mconnor)
Attachment #173519 - Flags: review?(mconnor) → review+
Checking in browser/base/content/browser.js;
/cvsroot/mozilla/browser/base/content/browser.js,v  <--  browser.js
new revision: 1.374; previous revision: 1.373
done
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Flags: blocking-aviary1.1?
Resolution: --- → FIXED
*** Bug 296167 has been marked as a duplicate of this bug. ***
As a Mac user, I find this new behaviour (post fix) strange. I would expect
Firefox on the Mac to function as other Mac browsers do:

command-return: opens link in new window/tab
command-shift-return: opens link in new window/tab (and temporarily inverts
"select new tabs")

Failing that, command-return should be nonfunctional or equivalent to return.

Maybe current behaviour is the right behaviour for Firefox, maybe not. Seems it
wasn't really discussed here. Is it too late to discuss it?
I'd expect the same thing.  In all my other link-dealings (pages, bookmarks),
Command means "in a tab".  I'm not sure about Cmd-shift needing to mean "invert
tab pref", but not having command-enter open in a tab is a mistake I make
several times a day.

That says something about me, to be sure, but I think it also says something
about the app.
to #26 & #27: 

I strongly, strongly disagree.  As a Firefox user from other platforms (and 
former IE user on Windows), I have become extremely used to the utility of 
having www. .com autocompletion with a hotkey.  I lobbied long and hard over 
the inclusion of this behavior in the Mozilla Suite, only to have the fix 
rejected by the developers.  It is because Firefox included this behavior that 
I'm using it as my main browser on the Macintosh platform.  Not having to 
manually type www. .com for each URL I go to (or having to wait for Google to 
search and return it's first result) is a major convenience.  If Firefox did 
not include this behavior, I might as well use Safari.

I do not understand the rationale behind having CMD-Enter do nothing rather 
than have it autocomplete www. .com.  It is by far more convenient to have it 
do something rather than do nothing.  Failing CMD-Enter (as CMD takes the place 
of CTRL on other platforms), then CTRL-enter should perform this behavior.
#28: Which browser did you use to use that had this functionality?

- Safari acts like it should, opening a new tab on command-return.
- Internet Explorer acts as it should, opening a new window on command-return.
- Omniweb acts as it should, opening a new tab on command-return.
- Mozilla acts as it should, opening a new window on command-return.
- Camino doesn't act like it should, but doesn't act in this weird way either. Command-return is simply 
nonfunctional there.

The problem is that a "fix" for this has been included in Deer Park. Had this bug not been fixed/
introduced, you wouldn't be seeing complaints here.
I think the current discussion really boils down to a question of what Firefox
is supposed to be, and BZ is probably not the best forum for that. From what I
know, Firefox was designed to provide a similar experience across its supported
platforms, whereas Camino was intended to be a Gecko-based browser aiming for
full compliance with Apple's human interface guidelines. In that spirit, I
suggested that a very useful feature found in the Windows and Linux builds be
properly implemented on the OS X build (especially since the keyboard shortcut
had already been documented in the help).

Losing the "open in new tab/window" shortcut wasn't a big deal for me, I just
hit Cmd-T or Cmd-N before typing the url, which seems more intuitive and
straightforward anyway.
I shuld probably point out that opt+return/opt+shift+return do work for opening
in a new tab.
#29

Firefox and Internet Explorer on the Windows platform provide said www. .com 
functionality when CTRL-Enter is pressed. 

That being said, I would have no problem with CTRL-Return were being used for 
this instead of CMD-Return (though CMD seems to take the place of CTRL on the 
Mac platform), but I definitely would not like to see this very useful shortcut 
go away.

I also fail to see how making CMD-Return do nothing except return (Camino 
behavior)is better than just keeping it the way it is.

That being said, I have absolutely no complaints about leaving things the way 
they are right now (in trunk builds as of 06/02) where CMD-Return autocompletes 
www. .com.
Having thought about this, I think things are fine for now. Long term I'd like the other behaviour to be 
available optionally on Windows and Linux as well. I do like the idea of platform consistency, I just don't 
agree about which platform's standard was picked. I miss these keyboard shortcuts on Windows and 
Linux, too. Fairly low priority, though. :)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: