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)
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•21 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•21 years ago
|
||
confirming RFE
Assignee: blake → hyatt
Status: UNCONFIRMED → NEW
Ever confirmed: true
QA Contact: mpconnor
Assignee | ||
Comment 3•20 years ago
|
||
David Hyatt is no more active in the project BUG should be reassigned
Updated•20 years ago
|
Assignee: hyatt → bugs
Assignee | ||
Updated•20 years ago
|
Flags: blocking1.0mac?
Comment 4•20 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•20 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•20 years ago
|
Component: General → Keyboard Navigation
Assignee | ||
Updated•20 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•20 years ago
|
||
*** Bug 263757 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 7•20 years ago
|
||
*** Bug 263764 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 8•20 years ago
|
||
*** Bug 264719 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 9•20 years ago
|
||
*** Bug 268708 has been marked as a duplicate of this bug. ***
Comment 10•20 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•20 years ago
|
Flags: blocking-aviary1.0mac?
Comment 11•20 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•20 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•20 years ago
|
||
By the way, its currently listed in the Mac shortcut list.
Comment 14•20 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•20 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•20 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•20 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•20 years ago
|
Flags: blocking-aviary1.1?
Assignee | ||
Comment 18•20 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•20 years ago
|
||
cleanup spaghetti code
Assignee | ||
Updated•20 years ago
|
Target Milestone: --- → Firefox1.1
Assignee | ||
Comment 20•20 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•20 years ago
|
Attachment #173461 -
Flags: review?(mconnor)
Comment 21•20 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•20 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•20 years ago
|
||
Attachment #173486 -
Attachment is obsolete: true
Attachment #173519 -
Flags: review?(mconnor)
Updated•20 years ago
|
Attachment #173519 -
Flags: review?(mconnor) → review+
Assignee | ||
Comment 24•20 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: 20 years ago
Flags: blocking-aviary1.1?
Resolution: --- → FIXED
Comment 25•19 years ago
|
||
*** Bug 296167 has been marked as a duplicate of this bug. ***
Comment 26•19 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?
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•19 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•19 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•19 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•19 years ago
|
||
I shuld probably point out that opt+return/opt+shift+return do work for opening in a new tab.
Comment 32•19 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•19 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
•