60498 - [rfe] Bookmark custom keywords should work in "open web location" dialog

Status: VERIFIED FIXED

(SeaMonkey :: UI Design, enhancement, P2)

Description

[Jesse Ruderman]

I have this in my bookmarks with the keyword "rfc":
http://community.roxen.com/developers/idocs/rfc/rfc%s.html

"rfc 1459" works in the location bar but not in the "open web location" dialog 
(ctrl-l).  Combined with bug 19446 (need keyboard shortcut to focus location 
bar), this bug makes the keyword feature less useful than it could be.

See also bug 38865, "[RFE] URL autocomplete in Open Web Location dialog".

Comment 1

[John Unruh]

According to the instructions here, it is not expected to work this way - 
http://home.netscape.com/bookmark/bestof/customize.html
"A bookmark's keyword can be typed into the location field to go to the 
bookmarked site."

Comment 2

[Jesse Ruderman]

I still think this is a bug, but I'll reopen it as an rfe since the docs aren't 
clear.  It seems to me that typing into ctrl-L should have the same effect as 
typing into the location bar.

Is there any reason keywords shouldn't work in the dialog?

Comment 3

[Blake Ross]

This is easy to fix, provided it's a good idea UI-wise.  Sounds fine to me.  
Matthew?

Comment 4

[Matthew T (active 1999-2002)]

Absolutely! As far as I can imagine, the address field in the Open Location 
dialog should offer *at least* the same features as the address field in the 
browser window. So if keywords work in the latter, they should work in the former 
as well.

Comment 5

[Paul Chen]

nav triage team:

reassinging component to xp apps, not a beta stopper. Should open location dialog 
do everything that URL bar does?

Comment 6

[Asa Dotzler [:asa]]

removing keyword.  nsbeta1- only applies to bugs assigned to ns engineers.

Comment 7

[Jesse Ruderman]

*** Bug 68597 has been marked as a duplicate of this bug. ***

Comment 8

[Blake Ross]

Attachment: [patch] fix this, move openLocation

Comment 9

[Blake Ross]

This patch looks long for this bug; it's not.  I just moved 
openLocation.xul/js/dtd/properties while I was touching some of them, since 
they don't belong in /browser, since they're accessed from other apps besides 
Navigator (this will also allow us to add the dialog to mailnews).  It also 
persists the last "Open in window:" setting.

I'll attach an openLocation.js diff that shows what changed in that file (very 
little), since you can't tell from the -uN diff.

Comment 10

[Blake Ross]

Attachment: [patch] diff -u of openLocation.js (in old spot)

Comment 11

[Blake Ross]

I see some arbitrary spacing issues, yes, I'll fix them. cc'ing alec for sr.

Comment 12

[Alec Flett]

you really don't need to do all that.. all you should have to do is add
persist="value" to the widget that holds the url, right? let xul persistence do
all the hard work.

Comment 13

[Blake Ross]

I don't think persist works for menulists, which is what I added here (the url 
remembering stuff already existed).  But in any case, does that persistence 
work across windows and sessions?  (Or do we not want that?)

Comment 14

[Alec Flett]

yep, it works across windows and sessions (which seems like the proper behavior
anyway)
but if you're right that persistence doesn't work for menulists, then sr=alecf
on the existing patch

Comment 15

[Blake Ross]

Cool. I'll go ahead and fix the url case, then, and ask ben or hyatt about the 
menulists.

Comment 16

[timeless]

r=timeless

Comment 17

[Blake Ross]

This was fixed.  It still doesn't work when the dialog is invoked from 
Composer, but we have a separate bug on that.

Comment 18

[Claudius Gayle]

VERIFIED Fixed with 2001053104 builds. (the persist works too)

Comment 19

[Ben Tremblay]

Fixed?
with 2002011103 it isn't ... no sign in dialog that it ever was. Point being:
keywords in location don't work and *from IRC chat* have remained unstable.
'Sup?

Comment 20

[Jesse Ruderman]

Ben: works fine for me using 2002 030604 on Windows 98.