Closed Bug 88274 Opened 23 years ago Closed 20 years ago

custom keywords don't work when selected from location bar

Categories

(SeaMonkey :: Location Bar, defect, P3)

defect

Tracking

(Not tracked)

RESOLVED FIXED
Future

People

(Reporter: jkng, Assigned: jwkbugzilla)

References

Details

Attachments

(3 files, 2 obsolete files)

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.1+) Gecko/20010627
BuildID:    2001062804

After typing in your custom keyword for a bookmark, the keyword gets added to
the location bar list with "http://" added in front of your keyword. If you
select the keyword from the location bar drop down, it will activate
search.netscape.com  Presumably, this would work if "http://" wasn't added to
the keyword by default.

Reproducible: Always
Steps to Reproduce:
1. Create a custom keyword for a bookmark
2. enter your keyword in the location bar to load bookmarked page
3. select your keyword from the location bar

Actual Results:  you're sent to search.netscape.com with your keyword queried

Expected Results:  "http://" should not be added to custom keyword and you
should be able to access your custom keyword from the location bar.
Seeing this annoyance in Build 2001062504 win32

Should this go to URL bar?
Status: UNCONFIRMED → NEW
Ever confirmed: true
I'm seeing this bug in 2001072512 on Linux too.
Has there been any progress on this--I notice this hasn't been touched in about
a month?
I was just about to file this bug myself (gotta love bugzilla queries!)

-> URL Bar.  Personally, I think that this should be stored as the webpage that
the custom keyword maps to.  So typing in 'bug 88274' in the location bar would
make http://bugzilla.mozilla.org/show_bug.cgi?id=88274 appear when i clicked the
dropdown to see the sites.  But that's my opinion.
Assignee: ben → alecf
Component: Bookmarks → URL Bar
reassign url bar bugs to new owner..
Assignee: alecf → blakeross
Joe was dying to have these bugs. Who am I to say no?
Assignee: blakeross → hewitt
Status: NEW → ASSIGNED
Priority: -- → P3
Target Milestone: --- → Future
*** Bug 108885 has been marked as a duplicate of this bug. ***
looks like this is fixed in 0.9.8?
Just an update: this issue seems to be still pertinent in 1.0 RC1
i can't repro this in win32 1.2a.  perhaps it was fixed?
i can't repro this in win32 1.2a.  perhaps it was fixed?
Still there: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624
Correction: it has been fixed but in the wrong place. Function
addToUrlbarHistory() is called from two places: executeUrlBarHistoryCommand() in
file content/navigator/sessionHistoryUI.js and handleURLBarCommand() in file
content/navigator/navigator.js. The first one resolves bookmarks correctly
before calling addToUrlbarHistory() - but it doesn't really need to, there
cannot be any keywords in the history anyway, it can only save correct URLs yet.
The second function calls addToUrlbarHistory(), resolving is done later by the
BrowserLoadURL() function, that's the bug. addToUrlbarHistory() cannot handle an
URL without a scheme, so it inserts this "http://". Copying two lines from
executeUrlBarHistoryCommand() to handleURLBarCommand() should solve the problem.
Attached patch Proposed patch (obsolete) — Splinter Review
I would like to have both keywords and URLs in the urlbar history but it would
probably break a lot of other things. Instead I changed handleURLBarCommand()
to resolve bookmark keywords before putting them into history. This patch also
changes the handler for the Go button to use handleURLBarCommand().
Attachment #142746 - Flags: review?(neil.parkwaycc.co.uk)
So, can anyone explain why we are trying to compare URIs in URLbar history?
erm, that's not true. my history has lots of keyword + params. i know because i
get tons of venkman caught exceptions. i'd much rather be able to see the item
and use it normally.

fwiw i just checked my urlbar dropdown and "Bug 236266" was in it, clicking that
item in the dropdown list worked 'correctly' (it's mapped to the same behavior
as the text is in this bugzilla).

note that I visited that bug in this session. would someone please provide
correct steps for me to reproduce the problem that they think needs to be fixed?

I'm using 2004021913 (1.7a?)
Assignee: hewitt → location-bar
Status: ASSIGNED → NEW
It doesn't seem to work when using keywords with parameters. You have to enter a
keyword without parameters, for example "gecko". The browser saves it as
http://gecko/ in the URLbar history. Next time when you try to type gecko you
get this address as a suggestion. If you klick on it is not resolved as a
bookmark keyword (because of http://) and the browser tries to connect to
http://gecko/ which doesn't work of course.

Neil has already objected that it should be possible to save keywords in the
history and I'm going to write a more general patch.
Neil: The comparison of URIs is probably a left-over from 1.4.

Shame on me, I didn't notice that the code has been rewritten since 1.4 and
misinterpreted it. addToUrlbarHistory() adds both to the URLbar history and the
global history. The main problem is with the global history that is used by
default for autocomplete in the URLbar. And there was already a "fix" for it
checking for spaces in the URL (that's why there is no problem if the keyword
has parameters).
Attachment #142746 - Flags: review?(neil.parkwaycc.co.uk)
Attached patch Patch v2Splinter Review
Cleans up addToUrlbarHistory(), removes URI comparison for the URLbar history,
resolves bookmark keywords before adding to the global history. Removes leading
and trailing spaces from the URL before processing in order to compare properly
(had to be fixed for BrowserLoadURL() as well).
Attachment #142746 - Attachment is obsolete: true
Attached patch Patch v2 with diff -w (obsolete) — Splinter Review
Attachment #142938 - Flags: review?(neil.parkwaycc.co.uk)
Attachment #142938 - Flags: review?(neil.parkwaycc.co.uk) → review+
Attachment #142938 - Flags: superreview?(alecf)
Attachment #142938 - Flags: superreview?(alecf) → superreview?(darin)
I'm sorry that I haven't had time to review this patch yet.  I will try to get
to it next week.
Comment on attachment 142938 [details] [diff] [review]
Patch v2

This patch looks fine to me.  Sorry for taking so long to review this...
somehow overlooked the line in my request queue :-(


>Index: sessionHistoryUI.js

>-              var rdfUri = ioService.newURI(rdfValue, null, null);

beware that newURI does more than just create a nsIURI instance; it
also normalizes the URI string.  so, if you are comparing raw URI
strings, you may want to normalize those URI strings first.

you can normalize a URI string like this:

   var normalizedSpec = ioService.newURI(spec, null, null).spec;

i don't know if this is useful or applicable here, but i just thought
i'd mention it.


sr=darin
Attachment #142938 - Flags: superreview?(darin) → superreview+
We have URL normalization (gURIFixup.createFixupURI) but only when adding the
URL to the global history. The URLbar history stores raw strings (could be
keywords or URLs without http://) so we don't want to normalize there. The
strings "g" and "http://g" don't mean the same thing in the URLbar history -
the first one could be a keyword.

The patch to be checked in is exactly the same but without the change to
navigator.xul - this issue has been fixed already.
Assignee: location-bar → trev
Status: NEW → ASSIGNED
Checking in navigator.js;
/cvsroot/mozilla/xpfe/browser/resources/content/navigator.js,v  <--  navigator.js
new revision: 1.544; previous revision: 1.543
done
Checking in sessionHistoryUI.js;
/cvsroot/mozilla/xpfe/browser/resources/content/sessionHistoryUI.js,v  <-- 
sessionHistoryUI.js
new revision: 1.50; previous revision: 1.49
done
Attachment #142939 - Attachment is obsolete: true
Checked it with build 2004080208
=> FIXED
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
OS: Windows 98 → All
Hardware: PC → All
Resolution: --- → FIXED
Product: Core → SeaMonkey
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: