From Bugzilla Helper: User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:0.9.5) Gecko/20011015 BuildID: 2001102910 command-L is for opening a location. if one switches into mozilla, you should be able to hit cmd-L and a new browser window should open prompting for a location Reproducible: Always Steps to Reproduce: 1. Switch to moz, making sure no windows are open 2. hit cmd-L Actual Results: nothing Expected Results: it should open a new blank window prompting for a location

brade/pchen/pink, i don't know if this is supposed to be expected behavior. is it?

I *think* the intended spec was for this behavior to happen. Sorry I don't recall where I saw this behavior described. I think this is a valid bug.

Reporter, how is your described desired behavior for Cmd-L different from Cmd-N? If you hit Cmd-N, a new window opens, with focus on the URL Bar.

It is a feature enhancement..... It is a habit for some people to press command+L...... And when there is no window open, it is a nice thing to have.

confirming as rfe --sorry, shoulda seen "enhancement" selected earlier on!

->marlon for ue consideration

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

Both "Open File" and "Open Location" do nothing on OSX if you have no window open. I came on this bug when doing a search prior to reporting the "Open File" bug. I've read the comments, and even if you don't want Open/* to work when there is no browser window open, the UI is still wrong and a bug. This is NOT an enhancement request, this is a bug. Since it is impossible to have a menu bar without an open window in mswin and linux, this issue probably slipped through the cracks. There are at least two correct behaviors the software could have, the current behavior is not one of them. Two that I could think of are: 1) Open File and Open Location are grey-d out if no browser window is open. 2) Open File and Open Location open a new browser window if selected when there is no browser window open. *opinion on* If you think that the product should do #1, then this should be a bug report. If you think that the product should do #2, then it is an RFE, but you still have to do #1 before you ship the software unless you are going to implement #2 right away.

if you think the correct behavior is (1), then we have another bug that covers that (something about too many enabled commands when no windows open...)

related issues: bug 83313: "open file" doesn't work when there are no windows bug 84001: "open web location" doesn't when there are no windows

With the cost associated with creating a New Window, especially if it loads the default home page (it probably ought not for cmd-L) a lightweight NS4-ish URL window might be a nice way of handling this if there are no open (or focused?) navigator windows.

Opera will open a new browser window if no browser window was open when its dock icon was clicked. Not ideal if new window loads a page. Opening a blank would be fine if Cmd-L were pressed. Cmd-L should open either a locator window - something for you to type an address into, (cf Opera 5) or a new Navigator window with cursor in the address bar (cf. IE 5.1). Ideally, any auto-complete options should apply to cmd-L function. BTW, Mozilla 0.9.8 (Build ID: 2002020516) does not always respond to cmd-N if no browser windows are open, either. Seemingly fails when File->New Navigator Window has not used since launching Moz; will always work to open new window if one exists already and will *sometimes* work when none exist.

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

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

This issue persists in SeaMonkey 2.0b1pre (Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1pre) Gecko/20090614 SeaMonkey/2.0b1pre) The desired behavior in this bug is to type cmd-L to open a new window with focus on the location bar when no windows are open. The browser does not yet match this behavior. Furthermore, the browser currently enters an odd state with no menu options when you type cmd-shift-L without any windows open.

(In reply to comment #18) > Furthermore, the browser currently enters an odd state with no menu options > when you type cmd-shift-L without any windows open. Yeah, see bug 356742.

It looks like this has regressed with Firefox 29 on Mac (OS X 10.7.5, at least). I use this very frequently :-(

(In reply to Matthew Cornell from comment #20) > It looks like this has regressed with Firefox 29 on Mac (OS X 10.7.5, at > least). I use this very frequently :-( Matthew, this is a SeaMonkey bug and Cmd+L with no windows open hasn't yet been implemented in SeaMonkey. If you see this with Firefox, you should file a report in the Firefox product component.

Oops! Sorry about that.