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

VERIFIED FIXED in Firefox1.5

Status

()

P2
normal
VERIFIED FIXED
14 years ago
14 years ago

People

(Reporter: mano, Assigned: mano)

Tracking

unspecified
Firefox1.5
PowerPC
Mac OS X
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 1 obsolete attachment)

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
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)
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+

Updated

14 years ago
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
Last Resolved: 14 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.