Closed
Bug 247467
Opened 20 years ago
Closed 19 years ago
Open Location Dialog does not recognize bookmark keywords nor quicksearch
Categories
(Firefox :: Address Bar, defect, P4)
Firefox
Address Bar
Tracking
()
VERIFIED
FIXED
Firefox1.5
People
(Reporter: takuo_mozilla_bugzilla_sia, Assigned: Gavin)
References
Details
Attachments
(1 file, 3 obsolete files)
3.67 KB,
patch
|
vlad
:
review+
benjamin
:
approval1.8b4+
|
Details | Diff | Splinter Review |
User-Agent: Mozilla/5.0 (X11; U; Linux i686; ja-JP; rv:1.6) Gecko/20040221 Firefox/0.8
Build Identifier: http://ftp.mozilla.org/pub/mozilla.org/firefox/releases/0.9/FirefoxSetup-0.9.exe
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
Luckey).
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, {});
Comment 1•20 years ago
|
||
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
Toolbar].
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.
Comment 3•20 years ago
|
||
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
Assignee | ||
Comment 4•20 years ago
|
||
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.
Status: UNCONFIRMED → NEW
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.
Assignee | ||
Updated•20 years ago
|
Attachment #158330 -
Flags: review?(bugs)
Assignee | ||
Updated•20 years ago
|
Summary: Open Location Dialog does not regcognize bookmark keywords nor quicksearch → Open Location Dialog does not recognize bookmark keywords nor quicksearch
Whiteboard: [have patch]
Comment 7•20 years ago
|
||
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?
Comment 8•20 years ago
|
||
not going to block on this.
Flags: blocking-aviary1.0? → blocking-aviary1.0-
Comment 9•20 years ago
|
||
https://bugzilla.mozilla.org/show_bug.cgi?id=194524
Is the bug 194524 a dupe of this one?
Assignee | ||
Comment 10•20 years ago
|
||
(In reply to comment #9)
> https://bugzilla.mozilla.org/show_bug.cgi?id=194524
> Is the bug 194524 a dupe of this one?
No
Version: unspecified → 1.0 Branch
Comment 11•20 years ago
|
||
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.
Comment 12•20 years ago
|
||
Wish I had known this was here, I figured it out and fixed it on my own for my
extension <a href="http://www.vrspace.com/projects/Firefox/">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.
Assignee | ||
Comment 13•20 years ago
|
||
Attachment #158330 -
Attachment is obsolete: true
Attachment #169326 -
Flags: review?(mconnor)
Assignee | ||
Updated•20 years ago
|
Attachment #158330 -
Flags: review?(bugs)
Assignee | ||
Updated•20 years ago
|
Attachment #169326 -
Attachment description: Patch against trunk, unbitrotted → Patch against trunk
Comment 14•20 years ago
|
||
(In reply to comment #13)
> Created an attachment (id=169326) [edit]
> Patch against trunk, unbitrotted
>
hmm, what about the other two cases (1 / 2)?
Assignee | ||
Comment 15•20 years ago
|
||
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)
Reporter | ||
Comment 16•20 years ago
|
||
(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 | ||
Updated•20 years ago
|
Assignee: bugs → gavin.sharp
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
Assignee | ||
Comment 17•20 years ago
|
||
This fixes all cases that I've tested.
Attachment #173901 -
Flags: review?(mconnor)
Assignee | ||
Comment 18•20 years ago
|
||
Comment on attachment 173901 [details] [diff] [review]
Patch v2
Argh
Attachment #173901 -
Attachment is obsolete: true
Attachment #173901 -
Flags: review?(mconnor)
Assignee | ||
Comment 19•20 years ago
|
||
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
Assignee | ||
Updated•20 years ago
|
Whiteboard: [patch-r?] → [wip]
Assignee | ||
Updated•20 years ago
|
Attachment #173901 -
Flags: review?(mconnor)
Assignee | ||
Updated•20 years ago
|
Whiteboard: [wip] → [patch-r?]
Assignee | ||
Updated•20 years ago
|
Attachment #173901 -
Flags: review?(mconnor) → review?(vladimir)
Assignee | ||
Updated•20 years ago
|
Status: NEW → ASSIGNED
Assignee | ||
Comment 20•20 years ago
|
||
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)
Assignee | ||
Updated•20 years ago
|
Attachment #173901 -
Flags: review?(vladimir)
Assignee | ||
Updated•20 years ago
|
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+
Updated•19 years ago
|
Attachment #176206 -
Flags: approval1.8b4?
Updated•19 years ago
|
Attachment #176206 -
Flags: approval1.8b4? → approval1.8b4+
Updated•19 years ago
|
Whiteboard: [patch-r?] → [checkin needed]
Comment 22•19 years ago
|
||
Let's get it landed once you're hooked up with CVS. :)
Flags: blocking-aviary1.1? → blocking1.8b4+
Assignee | ||
Updated•19 years ago
|
Whiteboard: [checkin needed] → [checkin needed][a+]
Comment 23•19 years ago
|
||
Checking in browser.js;
/cvsroot/mozilla/browser/base/content/browser.js,v <-- browser.js
new revision: 1.456; previous revision: 1.455
done
Checking in openLocation.js;
/cvsroot/mozilla/browser/base/content/openLocation.js,v <-- openLocation.js
new revision: 1.7; previous revision: 1.6
done
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Whiteboard: [checkin needed][a+]
Comment 24•19 years ago
|
||
Verified with Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b4) Gecko/20050716
Firefox/1.0+
Status: RESOLVED → VERIFIED
Assignee | ||
Comment 25•19 years ago
|
||
*** Bug 301660 has been marked as a duplicate of this bug. ***
Comment 26•19 years ago
|
||
(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?
Assignee | ||
Comment 27•19 years ago
|
||
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.
Description
•