If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Command-Enter does not open new tab/window from URL bar or search bar



Camino Graveyard
Tabbed Browsing
14 years ago
13 years ago


(Reporter: Jim, Assigned: Mike Pinkerton (not reading bugmail))


Mac OS X



(1 attachment, 2 obsolete attachments)



14 years ago
User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7) Gecko/20040514
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7) Gecko/20040514

When manually entering a URL, holding Command while hitting enter only beeps,
releasing command enters URL into current tab. A new tab can only be opened

Reproducible: Always
Steps to Reproduce:
1. Enter URL manually into address bar
2. Hold down command key and press enter
Actual Results:  
System beeps, and nothing happens

Expected Results:  
Open a new tab with the requested URL as in Mozilla or Safari

Comment 1

14 years ago

*** This bug has been marked as a duplicate of 164863 ***
Last Resolved: 14 years ago
Resolution: --- → DUPLICATE

Comment 2

14 years ago
Oops, didn't read carefully enough. Bug 164863 is about hitting command-enter on
a selected link. Reopening.

This should also work in the search bar, and it should open a new tab or window
according to user preference. This is a slick feature that I always miss after
using FF or Safari, so I'm nominating it for 0.9
Resolution: DUPLICATE → ---
Summary: Command-Enter does not open new tab from address bar → Command-Enter does not open new tab/window from URL bar or search bar
Target Milestone: --- → Camino0.9


13 years ago
Ever confirmed: true
still true with 2004090408 (v0.8+)
Created attachment 158954 [details] [diff] [review]
implements command-return for search bar, location bar

This patch implements the requested feature for command-return in both the
location bar and the search bar. It respects the user's prefs for
command-clicking. That is to say, if command-click opens a link in a new
window, command-return opens a search or url in a new window. If command-click
opens in a new tab, command-return does likewise. If new windows/tabs open in
the background, commmand-return generated new windows/tabs obey this.

This is my first cut, and there is some code duplication between the
command-return handler and the search/location handlers. The right way may be
to refactor those to minimize duplication, but this is far less invasive. Let
me know in the review if I should do the more invasive refactoring instead.
Attachment #158954 - Flags: review?(joshmoz)
Attachment #158954 - Flags: review?(joshmoz)
Created attachment 159829 [details] [diff] [review]
version 2

This version of the patch has exactly the same functionality but incorporates
Mike's comments from IRC and performs the refactoring instead of duplicating
Attachment #158954 - Attachment is obsolete: true
Attachment #159829 - Flags: review?(qa-mozilla)
Comment on attachment 159829 [details] [diff] [review]
version 2

looks good to me
Attachment #159829 - Flags: review?(qa-mozilla) → review+
Attachment #159829 - Flags: superreview?(pinkerton)

Comment 7

13 years ago
+typedef enum {
+  kDestinationNewWindow = 0,
+  kDestinationNewTab,
+  kDestinationCurrentView
+} BWCOpenDest;

nit. you don't need to typedef in C++, just C. this can be written as

enum BWCOpenDest { ... } ;

+-(void)performSearch:(SearchTextField *)searchField
inView:(BWCOpenDest)destination inBackground:(BOOL)loadInBG

name your params with in/out/io prefix to show they're parameters and not local

+    // revert the text in the URL bar since it goes into a new tab/window
+    [mURLBar revertText];

is this sufficient to get back to the previous url? what if they made other
changes before clearing it and typing this url? i'd say you should get the url
from the page and set it to that.

Created attachment 160362 [details] [diff] [review]
version 3

this should address pinkerton's comments.
Attachment #159829 - Attachment is obsolete: true
Attachment #159829 - Flags: superreview?(pinkerton)
Comment on attachment 160362 [details] [diff] [review]
version 3

moving sr request to the updated patch
Attachment #160362 - Flags: superreview?(pinkerton)

Comment 10

13 years ago
Last Resolved: 14 years ago13 years ago
Resolution: --- → FIXED

Comment 11

13 years ago
*** Bug 164863 has been marked as a duplicate of this bug. ***
Attachment #160362 - Flags: superreview?(pinkerton) → superreview+
marking sr+ since pink sr'd and landed, to get it off "my requests".
You need to log in before you can comment on or make changes to this bug.