Mac OS X: cmd-L no longer opens a new window when no window is available

VERIFIED FIXED in Firefox 32

Status

()

defect
VERIFIED FIXED
5 years ago
5 years ago

People

(Reporter: fluffy, Assigned: Gijs)

Tracking

({papercut, regression, ux-consistency})

29 Branch
Firefox 32
x86
macOS
Points:
---
Dependency tree / graph
Bug Flags:
firefox-backlog +

Firefox Tracking Flags

(firefox29 wontfix, firefox30- wontfix, firefox31- wontfix, firefox32 fixed, relnote-firefox 29+)

Details

(Whiteboard: p=2 s=it-32c-31a-30b.2 [qa-])

Attachments

(1 attachment, 1 obsolete attachment)

Reporter

Description

5 years ago
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:29.0) Gecko/20100101 Firefox/29.0 (Beta/Release)
Build ID: 20140506152807

Steps to reproduce:

1. Close all windows without quitting the app
2. Press cmd-L


Actual results:

The system made the default error beep at me


Expected results:

A new window should have opened with the location bar focused
Exact same thing happens when all windows are minimised.
It used to restore one of the minimised windows.
Reporter

Comment 2

5 years ago
Oddly enough, ⌘T to open a new tab does do the right thing still.
(In reply to fluffy from comment #2)
> Oddly enough, ⌘T to open a new tab does do the right thing still.

Confirmed.
Assignee

Updated

5 years ago
Depends on: 953124
Assignee

Updated

5 years ago
Duplicate of this bug: 1012755
Assignee

Updated

5 years ago
Status: UNCONFIRMED → NEW
Component: Untriaged → General
Depends on: 387849
No longer depends on: 953124
Ever confirmed: true
Flags: firefox-backlog+
Assignee

Comment 5

5 years ago
Dão, can we revert bug 387849 just for Mac?
Flags: needinfo?(dao)
(In reply to :Gijs Kruitbosch from comment #5)
> Dão, can we revert bug 387849 just for Mac?

We could. Whether we should actually do this probably depends on whether users commonly think of cmd-L in terms of "focus the location bar" or more metaphorically "open location" (which we even used to have a standalone dialog for for when the location bar would be hidden, but that behavior is also gone now).
Flags: needinfo?(dao)
Blocks: 387849
No longer depends on: 387849
I use cmd-L to focus on the location bar and to restore minimised windows with focus on the location bar.

I could also use cmd-K to focus on the search bar and to restore minimised windows with focus on the search bar. But it doesn't work either.
Reporter

Comment 8

5 years ago
Same here on cmd-K - although that hasn't worked for quite some time now.

Comment 9

5 years ago
A newbie question: Is this a regression, or intentional? I am still smarting from the somewhat arrogant removal of the essential feature of find working across tabs [1]. Thank you.

[1] 913536 – Opening findbar only assumes previous value the first time
https://bugzilla.mozilla.org/show_bug.cgi?id=913536
Assignee

Comment 10

5 years ago
(In reply to Dão Gottwald [:dao] from comment #6)
> (In reply to :Gijs Kruitbosch from comment #5)
> > Dão, can we revert bug 387849 just for Mac?
> 
> We could. Whether we should actually do this probably depends on whether
> users commonly think of cmd-L in terms of "focus the location bar" or more
> metaphorically "open location" (which we even used to have a standalone
> dialog for for when the location bar would be hidden, but that behavior is
> also gone now).

It seems that on OS X there is no sane way to unminimize/hide a minimized/hidden window (comment #1; cf. http://superuser.com/questions/196141/keyboard-shortcut-to-unhide-or-unminimize-a-window-in-os-x which I wouldn't call "sane"...) and "cmd-L" used to always focus a location bar - including one in a new window, or in a now-un-minimized-window, as appropriate, for which there now isn't a great alternative (cmd-T, then potentially close the excess tab, but maybe not, isn't as predictable, either).

IMO, we should revert it. I don't think we need to reinstate the dialog, but we should make the code that did this on OS X reachable again (it's still there, but I don't think there's currently a way it gets invoked).
(In reply to Matthew Cornell from comment #9)
> A newbie question: Is this a regression, or intentional?

It's an unforeseen consequence of the intentional removal of the menu item. Same for Cmd-K.

Comment 12

5 years ago
Much appreciated, Dao.
Assignee

Comment 13

5 years ago
This restores the item on mac's hidden window only. The <key> will ensure this works on normal windows without bothering with a menu item (which isn't really that useful). I've left out the access key because it's not functional on mac anyway.
Attachment #8425504 - Flags: review?(dao)
Assignee

Updated

5 years ago
Assignee: nobody → gijskruitbosch+bugs
Status: NEW → ASSIGNED
Comment on attachment 8425504 [details] [diff] [review]
add open location back on Mac hidden window,

>Bug 1008793 - add open location back on Mac hidden window, r?dao

and in other windows using macBrowserOverlay.xul, right?

>+#ifdef MAC_OVERLAY
>+                <menuitem id="menu_openLocation"
>+                          class="show-only-for-keyboard"
>+                          label="&openLocationCmd.label;"
>+                          command="Browser:OpenLocation"
>+                          key="focusURLBar"/>
>+#endif

show-only-for-keyboard doesn't work on OS X
Comment on attachment 8425504 [details] [diff] [review]
add open location back on Mac hidden window,

>+<!ENTITY openLocationCmd.label "Open Location…">

This could use a l10n not about where this string is used.
Assignee

Updated

5 years ago
Attachment #8425504 - Attachment is obsolete: true
Attachment #8425504 - Flags: review?(dao)
Comment on attachment 8425549 [details] [diff] [review]
add open location back on Mac hidden window and other macBrowserOverlay-using windows,

MAC_OVERLAY feels a bit nebulous to me, but I have no proposal for a clearer name.
Attachment #8425549 - Flags: review?(dao) → review+
maybe MAC_NON_BROWSER_WINDOW?
Assignee

Comment 19

5 years ago
remote:   https://hg.mozilla.org/integration/fx-team/rev/79d792c2f9f2
Whiteboard: [fixed-in-fx-team]
Assignee

Comment 20

5 years ago
(In reply to Dão Gottwald [:dao] from comment #18)
> maybe MAC_NON_BROWSER_WINDOW?

(went with this suggestion, btw)
https://hg.mozilla.org/mozilla-central/rev/79d792c2f9f2
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Whiteboard: [fixed-in-fx-team]
Target Milestone: --- → Firefox 32
Assignee

Comment 22

5 years ago
Marco, can you add this to the backlog?
Flags: needinfo?(mmucci)
Whiteboard: p=2 s=it-32c-31a-30b.2
Added to Iteration 32.2
Flags: needinfo?(mmucci)
Whiteboard: p=2 s=it-32c-31a-30b.2 → p=2 s=it-32c-31a-30b.2 [qa?]
Whiteboard: p=2 s=it-32c-31a-30b.2 [qa?] → p=2 s=it-32c-31a-30b.2 [qa-]
Status: RESOLVED → VERIFIED
Let's get this into tomorrow's Beta - please nominate for uplift.
Assignee

Comment 25

5 years ago
(In reply to Lukas Blakk [:lsblakk] from comment #24)
> Let's get this into tomorrow's Beta - please nominate for uplift.

I realized after requesting tracking that we can't. String addition. :-(
Oh well, we will have to let this ride the trains. I will flag for release note "known issue" in case that helps anyone who hits this.
Assignee

Updated

5 years ago
Duplicate of this bug: 1018974
Assignee

Updated

5 years ago
See Also: → 1064098
You need to log in before you can comment on or make changes to this bug.