Closed
Bug 220589
Opened 22 years ago
Closed 21 years ago
Cmd-Enter and Cmd-Shift-Enter should work like win/lin builds
Categories
(Firefox :: Keyboard Navigation, defect)
Tracking
()
RESOLVED
FIXED
Firefox1.5
People
(Reporter: aaron, Assigned: asaf)
References
Details
Attachments
(1 file, 2 obsolete files)
|
2.05 KB,
patch
|
mconnor
:
review+
|
Details | Diff | Splinter Review |
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.
Comment 1•22 years ago
|
||
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.
Comment 2•22 years ago
|
||
confirming RFE
Assignee: blake → hyatt
Status: UNCONFIRMED → NEW
Ever confirmed: true
QA Contact: mpconnor
| Assignee | ||
Comment 3•22 years ago
|
||
David Hyatt is no more active in the project BUG should be reassigned
Updated•22 years ago
|
Assignee: hyatt → bugs
| Assignee | ||
Updated•21 years ago
|
Flags: blocking1.0mac?
Comment 4•21 years ago
|
||
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.
Comment 5•21 years ago
|
||
> 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.
Updated•21 years ago
|
Component: General → Keyboard Navigation
| Assignee | ||
Updated•21 years ago
|
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
| Assignee | ||
Comment 6•21 years ago
|
||
*** Bug 263757 has been marked as a duplicate of this bug. ***
| Assignee | ||
Comment 7•21 years ago
|
||
*** Bug 263764 has been marked as a duplicate of this bug. ***
| Assignee | ||
Comment 8•21 years ago
|
||
*** Bug 264719 has been marked as a duplicate of this bug. ***
| Assignee | ||
Comment 9•21 years ago
|
||
*** Bug 268708 has been marked as a duplicate of this bug. ***
Comment 10•21 years ago
|
||
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
Updated•21 years ago
|
Flags: blocking-aviary1.0mac?
Comment 11•21 years ago
|
||
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.
Comment 12•21 years ago
|
||
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.
Comment 13•21 years ago
|
||
By the way, its currently listed in the Mac shortcut list.
Comment 14•21 years ago
|
||
(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.
Comment 15•21 years ago
|
||
> 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.
| Reporter | ||
Comment 16•21 years ago
|
||
(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?
Comment 17•21 years ago
|
||
(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.
Updated•21 years ago
|
Flags: blocking-aviary1.1?
| Assignee | ||
Comment 18•21 years ago
|
||
(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
| Assignee | ||
Comment 19•21 years ago
|
||
cleanup spaghetti code
| Assignee | ||
Updated•21 years ago
|
Target Milestone: --- → Firefox1.1
| Assignee | ||
Comment 20•21 years ago
|
||
|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)
| Assignee | ||
Updated•21 years ago
|
Attachment #173461 -
Flags: review?(mconnor)
Comment 21•21 years ago
|
||
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-
| Assignee | ||
Comment 22•21 years ago
|
||
(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.
| Assignee | ||
Comment 23•21 years ago
|
||
Attachment #173486 -
Attachment is obsolete: true
Attachment #173519 -
Flags: review?(mconnor)
Updated•21 years ago
|
Attachment #173519 -
Flags: review?(mconnor) → review+
| Assignee | ||
Comment 24•21 years ago
|
||
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: 21 years ago
Flags: blocking-aviary1.1?
Resolution: --- → FIXED
Comment 25•21 years ago
|
||
*** Bug 296167 has been marked as a duplicate of this bug. ***
Comment 26•21 years ago
|
||
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?
Comment 27•21 years ago
|
||
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.
Comment 28•21 years ago
|
||
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.
Comment 29•21 years ago
|
||
#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.
| Reporter | ||
Comment 30•21 years ago
|
||
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.
| Assignee | ||
Comment 31•21 years ago
|
||
I shuld probably point out that opt+return/opt+shift+return do work for opening
in a new tab.
Comment 32•21 years ago
|
||
#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.
Comment 33•21 years ago
|
||
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.
Description
•