Existing blank tabs not used for external links
 

This one's been around since 5.0, and it's open to interpretation whether it constitutes a bug or a feature request, but in any case is something I think should be taken care of.

When there is a blank tab already open in the drawer (for whatever reason), and an external application tells OmniWeb to open a URL, instead of using the existing blank tab, [I]another[/I] new tab is needlessly created, and then I have to close the first one. Since a blank tab is obviously not serving any purpose other than to eventually be used to load a page, I believe it can be safely assumed that a user [I]wanted[/I] that tab to be used in the next situation where a new tab is needed.

Although this isn't necessarily the only situation in which it happens, I am in the habit of sometimes creating a new tab when I want to be sure that a link from another program will not replace any of my currently-open tabs. I do have OmniWeb set to open external links in a new tab, but the behavior of OmniWeb's search field in the toolbar is such that it isn't possible to start a search in a new tab without manually creating the new tab before searching (since Command-return still doesn't work in that field; this in itself should be added as well, but that's another story), and this inconsistency is the main reason why I sometimes end up creating new tabs in other situations where it's not necessary. In those cases -- or in any other situation where a new tab was created but not used for anything -- that tab should be used for anything that tries to create a new tab, rather than creating [I]another[/I] new one.

I'm all for consistency. If clicking on a link in another app is set to open a new tab, it should always open a new tab.

Also, a new tab is only blank if the prefs are set that way. Someone may want their new tab not to be disturbed because they have a start page selected.

Fair enough. As an alternative suggestion, then, the search field should support pressing Command-Return to open the search results in a new tab.

And on a similar note, Option-Return in the address bar should download the file at the given URI instead of opening it in the window (in keeping with the fact that one can Option-click a link to download it). Currently the only way to do it is to use the File > Open Location command, then choose "Downloads Window" from a drop-down menu (which doesn't remember your most recent setting, so this always involves several steps).

[QUOTE=Stormchild]Currently the only way to do it is to use the File > Open Location command, then choose "Downloads Window" [...][/QUOTE]
Actually, you can also edit the URL in the location field and then drag the icon to the downloads window to start a download...

That said, I like the alt-return idea, just don't know when we can get to it...

Yep. alt+return "makes sense." As far as the search string goes, you can hit command+L, type your search keyword and string, then hit command+return and you'll get your result. There's another thread on that somewhere around here.

[QUOTE=Forrest]Yep. alt+return "makes sense." As far as the search string goes, you can hit command+L, type your search keyword and string, then hit command+return and you'll get your result. There's another thread on that somewhere around here.[/QUOTE]

I love search keywords; it's one of the [I]key[/I] features that have kept me from jumping ship even as OW 5.1 fell way behind Safari's speed and rendering accuracy (and with OW 5.5 I can happily say the tables have turned -- wow, two bad puns in the same sentence). I actually only use the toolbar search for Google, and keywords for everything else, but I really ought to just yank that off the toolbar and get in the habit of searching Google in the same way. Good idea.