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)
SeaMonkey
Location Bar
Tracking
(Not tracked)
RESOLVED
FIXED
Future
People
(Reporter: jkng, Assigned: jwkbugzilla)
References
Details
Attachments
(3 files, 2 obsolete files)
9.09 KB,
patch
|
neil
:
review+
darin.moz
:
superreview+
|
Details | Diff | Splinter Review |
8.07 KB,
patch
|
Details | Diff | Splinter Review | |
5.45 KB,
patch
|
Details | Diff | Splinter Review |
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?
Comment 3•23 years ago
|
||
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
Comment 5•23 years ago
|
||
Joe was dying to have these bugs. Who am I to say no?
Assignee: blakeross → hewitt
Updated•23 years ago
|
Status: NEW → ASSIGNED
Priority: -- → P3
Target Milestone: --- → Future
Comment 6•23 years ago
|
||
*** Bug 108885 has been marked as a duplicate of this bug. ***
Comment 7•22 years ago
|
||
looks like this is fixed in 0.9.8?
Comment 8•22 years ago
|
||
Just an update: this issue seems to be still pertinent in 1.0 RC1
Comment 9•22 years ago
|
||
i can't repro this in win32 1.2a. perhaps it was fixed?
Comment 10•22 years ago
|
||
i can't repro this in win32 1.2a. perhaps it was fixed?
Assignee | ||
Comment 11•21 years ago
|
||
Still there: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624
Assignee | ||
Comment 12•21 years ago
|
||
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.
Assignee | ||
Comment 13•20 years ago
|
||
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().
Assignee | ||
Updated•20 years ago
|
Attachment #142746 -
Flags: review?(neil.parkwaycc.co.uk)
Comment 14•20 years ago
|
||
So, can anyone explain why we are trying to compare URIs in URLbar history?
Comment 15•20 years ago
|
||
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
Assignee | ||
Comment 16•20 years ago
|
||
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.
Assignee | ||
Comment 17•20 years ago
|
||
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).
Assignee | ||
Updated•20 years ago
|
Attachment #142746 -
Flags: review?(neil.parkwaycc.co.uk)
Assignee | ||
Comment 18•20 years ago
|
||
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
Assignee | ||
Comment 19•20 years ago
|
||
Assignee | ||
Updated•20 years ago
|
Attachment #142938 -
Flags: review?(neil.parkwaycc.co.uk)
Updated•20 years ago
|
Attachment #142938 -
Flags: review?(neil.parkwaycc.co.uk) → review+
Assignee | ||
Updated•20 years ago
|
Attachment #142938 -
Flags: superreview?(alecf)
Assignee | ||
Updated•20 years ago
|
Attachment #142938 -
Flags: superreview?(alecf) → superreview?(darin)
Comment 20•20 years ago
|
||
I'm sorry that I haven't had time to review this patch yet. I will try to get to it next week.
Comment 21•20 years ago
|
||
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+
Assignee | ||
Comment 22•20 years ago
|
||
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
Comment 23•20 years ago
|
||
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
Assignee | ||
Comment 24•20 years ago
|
||
Attachment #142939 -
Attachment is obsolete: true
Assignee | ||
Comment 25•20 years ago
|
||
Checked it with build 2004080208 => FIXED
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
OS: Windows 98 → All
Hardware: PC → All
Resolution: --- → FIXED
Updated•16 years ago
|
Product: Core → SeaMonkey
You need to log in
before you can comment on or make changes to this bug.
Description
•