Closed Bug 293737 Opened 20 years ago Closed 19 years ago

Improve the way "Open Location" and "Web Search" menu commands work in non-browser windows (on mac)

Categories

(Firefox :: Menus, defect, P2)

PowerPC
macOS
defect

Tracking

()

VERIFIED FIXED
Firefox1.5

People

(Reporter: asaf, Assigned: asaf)

References

Details

Attachments

(1 file, 1 obsolete file)

In bug 239218 (in which we've enabled the browser menubar for menuless windows), I've patched the "Open Location" menu item to open a new browser window, once it's fired from a non-browser window. However, Mike and I have agreed it would be better to focus the url bar of the frontmost browser window (and only if there are no browser windows, open a new one). In addition, we should enable the "Web Search" menu item in non-browser windows and make it work in the same way.
Status: NEW → ASSIGNED
Priority: -- → P2
Target Milestone: --- → Firefox1.1
Attached patch v1 (obsolete) — Splinter Review
Attachment #183280 - Flags: review?(mconnor)
Blocks: deermac
Blocks: macmeta
Summary: [Mac] Improve our handling of "Open Location" and "Web Search" menu commands in non-browser windows → Improve the way "Open Location" and "Web Search" menu commands in non-browser windows (on mac)
Summary: Improve the way "Open Location" and "Web Search" menu commands in non-browser windows (on mac) → Improve the way "Open Location" and "Web Search" menu commands work in non-browser windows (on mac)
Attached patch v1.1Splinter Review
Attachment #183280 - Attachment is obsolete: true
Attachment #185673 - Flags: review?(mconnor)
Attachment #183280 - Flags: review?(mconnor)
Comment on attachment 185673 [details] [diff] [review] v1.1 >+ else { >+ openDialog("chrome://browser/content/openLocation.xul", "_blank", >+ "chrome,modal,titlebar", window); > } > } drop the brackets here :)
Attachment #185673 - Flags: review?(mconnor) → review+
Attachment #185673 - Flags: approval-aviary1.1a2?
Attachment #185673 - Flags: approval-aviary1.1a2? → approval-aviary1.1a2+
Checking in base/content/browser-sets.inc; /cvsroot/mozilla/browser/base/content/browser-sets.inc,v <-- browser-sets.inc new revision: 1.48; previous revision: 1.47 done Checking in base/content/browser.js; /cvsroot/mozilla/browser/base/content/browser.js,v <-- browser.js new revision: 1.429; previous revision: 1.428 done
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
tested with 2005060907-trunk (deer park) on OS X 10.4.1. some observations/questions --notably item (2): 1. with no windows, homepage set to google.com, where initial focus is in google's search field on the page: Cmd+L opens a new window at google.com, with focus in the google search field --as I would expect. 2. same as (1), except the homepage is to wired.com, where initial focus is not in any html form field, but just the overall content. results: Cmd+L brings focus to the Location bar, but the caret is at the end of the URL --shouldn't it select the entire URL content? 3. same as (1), but it doesn't matter what the homepage is set to, since I hit Cmd+K instead: as expected, the caret is in the Web Search bar. I'll compare the behavior on Camino and Safari (where applicable).
in both Camino (2005060708-trunk) and Safari (v2.0), scenarios (1) and (2) had the same result, since it didn't matter what the homepage was set to: when there are no windows, Cmd+L opens a new, blank browser window with the caret in the Location bar. the result for (3) wrt Web Search bar behaves in a similar manner where a new, blank window appears, and the caret in the Web Search bar.
I didn't plan to open the homepage on Command+L, bah.
spun off bug 297230. marking this one verified.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: