Closed Bug 247467 Opened 18 years ago Closed 17 years ago

Open Location Dialog does not recognize bookmark keywords nor quicksearch


(Firefox :: Address Bar, defect, P4)






(Reporter: takuo_mozilla_bugzilla_sia, Assigned: Gavin)




(1 file, 3 obsolete files)

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; ja-JP; rv:1.6) Gecko/20040221 Firefox/0.8
Build Identifier:

When the Navigation toolbar is hidden and you press Ctrl+L, the old style
location window pops up(the one that looks like Ctrl+****+L in Mozilla). When typing
a bookmark keyword, the Firefox search keyword in google (and go I'm Feeling
Lackey) insted of translate it to uri regstered in bookmark.

From locatoin bar, you can still use bookmark keywords or quicksearch.

Reproducible: Always
Steps to Reproduce:
1. Hide Navigation toolbar
2. Press Ctrl+L to bring up "open location" dialog box.
3. Enter a bookmark keyword or quicksearch and press <enter>

Actual Results:  
The Firefox search keyword in google and jump to page listed top (I'm Feeling

Expected Results:  
jumps to url regstered in bookmark

This bug can be fixed by replaceing
 url = browser.getShortcutOrURI(dialog.input.value);
in opneLocation.js to
 url = browser.getShortcutOrURI(dialog.input.value, {});
Ctrl+L in FX 0.9 takes my cursor to the url bar.  it does not bring up and "open
location" dialog.  I don't even see an "open location" in the file menu or any
other menu for that matter.

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040614 Firefox/0.9
Please hide the navigation toolbar from the menu [view]->[Toolbars]->[Navigation

When Ctrl+L pressed, Fifefox move the cursor to the location bar if location bar
is shown, but it shows open location dialog if location bar is not shown.

I use the RadialContext extention.  It covers functions of navigatoin toolbar,
so I hide the navigation toolbar.  The mouse gesture extention will also covers
functions of navigation toolbar.  Therefore there may be a lot of peoples who
hide the navigation toolbar.
ok.. you have to hide the url bar for this to work.

Steps to reproduce:
1) Hide urlbar
2) Press Ctrl+L to bring up "open location" dialog
3) Enter desired keyword

Actual Results:
FireFox does a search for the keyword entered

Expected Results:
FireFox opens the bookmark registered with the keyword

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040614 Firefox/0.9
Severity: minor → major
I can make the patch if you'd like. Are you sure that those changes solve the
problem with no side effects? I'm not able to test it right now.
Ever confirmed: true
Thank you.  Please make the patch.
I have not experienced any problem with the fix.
Reffering to browser.js, the following code may be better.

var uri;
var postData = {};
if (browser)
    url = browser.getShortcutOrURI(dialog.input.value, postData);
          browser.loadURI(url, null, postData.value); // Just do a normal load.
Attached patch Patch per comment 5 (obsolete) — Splinter Review
Makes the changes mentioned in comment 5.
Attachment #158330 - Flags: review?(bugs)
Summary: Open Location Dialog does not regcognize bookmark keywords nor quicksearch → Open Location Dialog does not recognize bookmark keywords nor quicksearch
Whiteboard: [have patch]
Uuuh we heavily promote this feature for FF1.0 and it's not fully working. Can
anyone take a look at the patch? Could we get it into AVIARY?

Asking for blocker.
Flags: blocking-aviary1.0?
not going to block on this.
Flags: blocking-aviary1.0? → blocking-aviary1.0-
(In reply to comment #9)
> Is the bug 194524 a dupe of this one?

Version: unspecified → 1.0 Branch
I'd like to report on this one as well.  It seems like a simple fix.  I find
myself needing as much screen space as posible, so i hide the location bar and
jsut use the Open Location dialog as well.

This would be a welcome fix for the next version of Firefox.

Thanx for the best browser on the web.
Wish I had known this was here, I figured it out and fixed it on my own for my
extension <a href="">OpenBox</a>. If you
don't want to wait for the bug to be fixed, you might try it. 

It also fixes the height of the textbox, and adds a pref to choose the default
"Open In" method. It's not elegant, since I haven't programmed in years nor do I
know javascript or XUL, but it works.
Attached patch Patch against trunk (obsolete) — Splinter Review
Attachment #158330 - Attachment is obsolete: true
Attachment #169326 - Flags: review?(mconnor)
Attachment #158330 - Flags: review?(bugs)
Attachment #169326 - Attachment description: Patch against trunk, unbitrotted → Patch against trunk
(In reply to comment #13)
> Created an attachment (id=169326) [edit]
> Patch against trunk, unbitrotted

hmm, what about the other two cases (1 / 2)?
Comment on attachment 169326 [details] [diff] [review]
Patch against trunk

I need to look into this a little further.
Attachment #169326 - Attachment is obsolete: true
Attachment #169326 - Flags: review?(mconnor)
(In reply to comment #13)
Yes, loadURI of case "0" must be fixed too.

By the way, what processes do we need to commit the patch?  I'm not familiar
with development of mozilla.
Assignee: bugs →
Severity: major → normal
OS: Windows XP → All
Priority: -- → P4
Hardware: PC → All
Whiteboard: [have patch] → [patch-r?]
Target Milestone: --- → Firefox1.1
Version: 1.0 Branch → Trunk
Attached patch Patch v2 (obsolete) — Splinter Review
This fixes all cases that I've tested.
Attachment #173901 - Flags: review?(mconnor)
Comment on attachment 173901 [details] [diff] [review]
Patch v2

Attachment #173901 - Attachment is obsolete: true
Attachment #173901 - Flags: review?(mconnor)
Comment on attachment 173901 [details] [diff] [review]
Patch v2

This fixes all cases except "Open in a New Window" with a plugin that uses
POST, since there is no way to submit post data to a new window. The only
solution I can think of is to add another parameter to the
openDialog(browser.xul) call, but the parameter parsing in browser.js's
Startup() is kind of ugly at the moment and I haven't gotten around to it.
Attachment #173901 - Attachment is obsolete: false
Whiteboard: [patch-r?] → [wip]
Attachment #173901 - Flags: review?(mconnor)
Whiteboard: [wip] → [patch-r?]
Attachment #173901 - Flags: review?(mconnor) → review?(vladimir)
Attached patch Patch v3Splinter Review
Hmm, guess there is an easy way to pass post data to a new window... It wasn't
obvious looking at browser.js, in any case.

This patch now works in the three cases (new window, new tab, same window).
Attachment #173901 - Attachment is obsolete: true
Attachment #176206 - Flags: review?(vladimir)
Attachment #173901 - Flags: review?(vladimir)
Flags: blocking-aviary1.1?
Comment on attachment 176206 [details] [diff] [review]
Patch v3

r=vladimir (sorry for not seeing this until now!)
Attachment #176206 - Flags: review?(vladimir) → review+
Attachment #176206 - Flags: approval1.8b4?
Attachment #176206 - Flags: approval1.8b4? → approval1.8b4+
Whiteboard: [patch-r?] → [checkin needed]
Let's get it landed once you're hooked up with CVS. :)
Flags: blocking-aviary1.1? → blocking1.8b4+
Whiteboard: [checkin needed] → [checkin needed][a+]
Checking in browser.js;
/cvsroot/mozilla/browser/base/content/browser.js,v  <--  browser.js
new revision: 1.456; previous revision: 1.455
Checking in openLocation.js;
/cvsroot/mozilla/browser/base/content/openLocation.js,v  <--  openLocation.js
new revision: 1.7; previous revision: 1.6
Closed: 17 years ago
Resolution: --- → FIXED
Whiteboard: [checkin needed][a+]
Verified with Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b4) Gecko/20050716
*** Bug 301660 has been marked as a duplicate of this bug. ***
(In reply to comment #25)
> *** Bug 301660 has been marked as a duplicate of this bug. ***

Are you sure 301660 is a dupe? I can trigger 301660 with the Location Toolbar
showing, which seems to directly contridict this bug?
This bug fixed the handling of keywords in the Open Location dialog, which is
what your bug is about. How you open that dialog doesn't matter.
You need to log in before you can comment on or make changes to this bug.