User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030723 Mozilla Firebird/0.6 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030723 Mozilla Firebird/0.6 alt-enter is used to open addresses typed in the location bar or search results queried from the search bar in a new tab. However, links (selected with tab) are openned in a new tab using ctrl-enter; alt-enter does nothing. Reproducible: Always Steps to Reproduce: 1. Open any web page with links (anchored hrefs) 2. Use the tab key (or cursor browsing) to highlight a link. 3. Press ctrl-enter to open link reference in new tab; press alt-enter to do nothing. Actual Results: Ctrl-enter: opens link in new tab alt-enter: does nothing Expected Results: ctrl-enter: do nothing? alt-enter: open link in new tab

Works for me with 20030724 build on W2K. Try anewer build with a new profile.

Confirming with 20030725 Linux build from CVS. This is not about opening pages from the URL bar but rather links in pages. Go to http://www.mozilla.org Start typing "At" or otherwise bring the focus to the "At A Glance" link. Hit Alt+Enter. Nothing happens. Hit Ctrl+Enter, and the page opens in a new tab. Use Shift+Enter and it opens in a new Window. Shift+Ctrl+Enter opens in a new foreground tab (or background if you've reversed the setting). This may or may not be intended - it does correspond to the modifier+Left-click combinations. On those grounds then Alt+Enter should open a save dialog. Because of that possibility I'm broadening the summary to a more general one. In some ways it would have been better to leave Ctrl+Enter (everywhere) to open in a new tab, Shift+Enter to open in a new window (again, everywhere) and then have Alt+Enter and Alt+Left-Click open a save dialog on links whilst Alt+Enter in the URL bar did the IEish thing. Ctrl+Alt+Enter could have been to append .org and Shift+Alt+Enter could have been .net. But that's just me dreaming...

This bug is the fallout from a discussion on Mozillazine: http://forums.mozillazine.org/viewtopic.php?t=16900&highlight= (and to campaign while being helpful...) I maintain that the alt+enter for a new tab in the location bar is inconsistent with the rest of the UI (which uses the ctrl modifier). Keyboard shortcuts taken from other applications is one thing, but it shouldn't override consistency with the rest of the app.

-> taking to evaluate

.

So basically, the real answer is to make Alt-Enter universal, not Ctrl-Enter. That's the solution, or a WONTFIX, because Ctrl-Enter isn't changing, period.

By that I assume you mean the following?: Alt+Enter in URL/Search bar - open in new tab Alt+Enter on a link - open in new tab Alt+Left-Click on a link - open in new tab Ctrl+Enter in URL bar - www.*.com Ctrl+Enter on a link - save dialog? Ctrl+Left-Click on a link - save dialog? Shift+Enter in URL bar - www.*.net (should be .org IMHO) Shift+Enter on a link - open in new window (current behaviour) Shift+Left-Click on a link - open in new window (current behaviour) The silly thing about that is that it is a reversal of what is in Mozilla, so we might actually be better off with: Ctrl+Enter on a link - open in new window (default Moz behaviour) Ctrl+Left-Click on a link - open in new window (default Moz behaviour) Shift+Enter on a link - save dialog (current Moz behaviour) Shift+Left-Click on a link - save dialog (current Moz behaviour) I think that's about the best we can hope for - retain Ctrl+Enter = IE in the URL bar whilst retaining Moz behaviour for Shift (old NS in fact) and Ctrl on links.

ben, if we flip the Ctrl and Alt modifiers, this would be more consistent UI. The patch is easy enough, but you're the UI guy, so its your call.

Ctrl+Click (on a link) is used to open in a new tab Ctrl+Enter (on a link) is used to open in a new tab Alt+Click (on a link) is used to Save As... Alt+Enter (on a link) does nothing. <-- BUG! There is no reason to make this bug become a discussion about the special case implementation in the location bar. That is a completely separate history. The reason why Ctrl+Enter is used to appent www. and .com in the location bar is because of the huge number of IE users expecting that. David Hyatt, the leader of the whole Firebird project, made that decision. This bug is about Alt+Enter (on a link) does nothing, and that is a bug since Alt+Click on a link brings up the Save As dialog. Let's fix this and discuss the Location bar behavior in a separate bug.

...and I can't spell. Also, I forgot to mention yet another argument for this being and inconsistency: Shift+Click (on a link) is used to open in a new window Shift+Enter (on a link) is used to open in a new window Simply put, Enter == Click (on links, with the exception of this bug).

David: I think you've misunderstood what Mike and I were discussing earlier. We have no intention of changing behaviour in the location bar (just ignore the third paragraph of my comment #2). When Mike suggested flipping Ctrl and Alt, he meant flipping them on links, so that Alt always opens in a new tab. Right now it's inconsistent. Doing what I suggested in comment #7 would solve (1) the Alt & Ctrl inconsistencies and (2) retain the old default NS/Moz behaviour for opening new windows (Ctrl+Click/Enter) and saving pages (Shift+Click/Enter). Given that in the short term most FB converts will be coming from Mozilla, it makes sense to do it this way. Furthermore, a number of IE converts will be old NS users, who may also know about the Ctrl and Shift combinations. So unless there is some good reason for Shift+Click/Enter to open in a new window (does IE do this?) I think we should aim for Moz compatibility as much as possible.

Shift+Click was changed to open a new window to be compatible with IE and Opera. That should NOT change in favor of Seamonkey compatibility. The inconsistency in the location bar is not a problem and Hyatt was well aware of that when he implemented this, as shown in the attachment.

I'm just attaching this for everyone to see that Hyatt made the current implementation to be compatible with most browsers and to still be very useful. It's compatible with IE and Opera, it's compatible with IE in the location bar. That's important. What he forgot, however, was make it so that Alt+Enter worked the same way as Alt+Click. Can we just fix this Alt+Enter bug, then discuss this minor inconsistency in the location bar in another bug?

This is not about the location bar, but the rendering area. The location bar is a Cotswolds of inconsistencies so thick it's not even worth getting into; I just accept that it's an unreconcilable mess (Alt+Ctrl+Enter works in Linux but not Windows, etc etc). I even remember that discussion (I lost unfortunately), and I remember thinking that we were breaking stuff needlessly. Shift+ = Save As has been around for eons, and most of the people we can hope to easily convert (Mozilla, NS + old NS users now using IE) will all be used to it. How many IE users even use Shift+ on links? (the only ones who do are probably ex-NS users who were once trying to save something and discovered that MS had done something else...) Whatever. Let's fix this as David suggests as well as a related bug, that being that Alt+Left-click doesn't even work on Linux anymore, bug 186681.

odd thing is, the code that handles this should support Alt-Enter, since I can change Alt vs. Ctrl, and then its Ctrl-Click working, Ctrl-Enter not something else is broken specifically for using Enter for this function

according to timeless, *-Enter is horked on Windows, but not in all instances, there's a bug somewhere on this, I'll go a-looking when I get to this bug.

*** Bug 223534 has been marked as a duplicate of this bug. ***

http://lxr.mozilla.org/mozilla/source/browser/base/content/browser.js#685 is where this breaks, still looking

-> me

Fixed.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040714 Firefox/0.9.1+ Alt+Enter now saves... and beeps. It shouldn't beep.

And it doesn't work after clicking a child of an <a> element.

To clarify comment 22: mousedown on <a><b>foo</b></a> and drag away. then press alt+enter. nothing happens. Comment 21 WFM on trunk (but not in 1.0.4). Comment 22 WFM on trunk (but not in 1.0.4). Changing resolution back to FIXED.

vrfy'd fixed with 2005061405-trunk deer park bits on linux fc3.