custom keyword queries are not bookmarks. Separate them.



16 years ago
14 years ago


(Reporter: m_mozilla, Assigned: mpt)


Firefox Tracking Flags

(Not tracked)




16 years ago
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.1b) Gecko/20020721
BuildID:    2002072103


Custom Keyword queries (those keywords to bookmarks with %s tokens)
are *not* valid bookmarks. You can't go to those "URL"s because they
are not URLs. They are "URL Templates".

These "bookmarks" are not bookmarks and should not be available in
the bookmarks menu. Users should not be confused into thinking that
they are the same thing because they are not.

I don't have any clear ideas on what the best presentation would be,
but I doubt that it is to call non-bookmarks bookmarks.


Reproducible: Always
Steps to Reproduce:
create a custom keyword query
select it in your bookmarks menu

Actual Results:  get taken to some URL with %s in it

Expected Results:  it shouldn't have let you select a non-bookmark from the
bookmarks menu

Comment 1

16 years ago
in bug 99860 you say: [The keyword] "p will take you to an existing which *does* redirect to the root of the site." 

So the bookmarks also work as bookmarks. Anyone savy enough to create bookmarks
with "%s" in them will also know how to use them.

Unless you can come up with a UI for handling bookmarks with "%s" that is
*better* than the current implementation, I suggest marking this bug WONTFIX.


Comment 2

16 years ago
> in bug 99860 you say

...but I *also* say "We shouldn't expect everyone to start guessing where we
want to put our %s tokens, and making the referenced resources actually valid."

> So the bookmarks also work as bookmarks.

...but only if the webmaster cooperates. We can't expect every webmaster to
cooperate with every possible use of %s in URIs at their site.

> Anyone savy enough to create bookmarks with "%s"
> in them will also know how to use them.

But if there were a more discoverable interface, then maybe it wouldn't be one
of those "you need to know the secret" things. If they were seperated from
bookmarks in a clear fashion, then Mozilla could ship with a couple dozen custom
keyword queries by default. I'm sure Netscape would love that because they could
get all sorts of partnering dollars.

However, if you tried to ship with CKQ in current mozilla, all users would see
is that they have a bunch of bookmarks that don't work correctly.

> Unless you can come up with a UI for handling bookmarks with "%s" that 
> is *better* than the current implementation, I suggest marking this bug

I'm not a UI expert, so my hope was that folks would see this fix as a good
thing, and then UI experts would figure out the best way to do it.

However, if that's not to happen, then I'll take a stab at it...

step 1: create a Tools->Custom Keyword Query Manager
        works like managing bookmarks, but properties dialog
           - does not have schedule or notify tabs
           - has some documentation (or link to same)
             explaining CKQs instead of bookmarks
           - hilights %s in the URI templates
           - shows sample of how URI template translates into URI

        So, editing an entry might have something like

           (docs or link to same)

           Name: __________________________
           URI Template: __________________
           Keyword: _______________________
           |                              |

           Example: typing this
               keywordhere foo
           takes you to this URL:

        If no URI Template or no keyword was specified, the
        example section would contain instructions to provide
        the missing info. If the URI Template had no %s in it
        then the example section would instruct the user to
        put a %s for the search term, and advise them to use
        a bookmarks instead if they don't have a variable search

For the URLBar, if the text contains non-whitespace then whitespace then
non-whitespace, then we can reasonably look for a CKQ. If the first token does
not match a keyword from a CKQ, then the whole string gets passed to the default
keyword search (google for me, "Internet Keywords" for Netscape). If the URLBar
doesn't appear to contain multiple words, then it is evaluated against the
keywords in the bookmarks list, and then as a URL and then as a partial URL
(like or something).

So, you can have a bookmark with keyword "amazon" and a CKQ with keyword amazon
and they can both have functional and meaninful interpretations. The bookmark is
what you get when you just type "amazon" and takes you to their home page or
maybe your amazon wishlist or whatever. The CKQ amazon is invoked when you type
"amazon foo" and probably searches for "foo".

This gets rid of "Schedule" and "Notify" tabs in CKQ bookmarks (which didn't
really have any meaning). It gets rid of non-functional CKQ entries in the
Bookmarks menu and sidebar. It provides a slightly more discoverable UI for
maintaining CKQs.

I don't think CKQs are common enough to warrant a contextual menu item on each
page, but certainly there could be a menu item. Maybe

        Custom Keyword Query Manager ->
            Build Custom Query From This Page...
            Manage Custom Keyword Queries...

Perhaps it could even be so savy as to do the following when you want to build a
CKQ from a page:
    show URL, ask user to hilight the variable part and click OK
    then ask for a keyword (keep asking if they use existing CKQ word)
    then bring up the above-described dialog pre-filled

If there is a wizard, it shouldn't presupose that CKQs only apply to GET-encoded
CGI parameters. There are many times when a bunch of static documents can be
usefully accessed via CKQ (for example, a site of RFCs with rfc%s.html documents).

I don't think that this would involve any change to the bookmarks UI. It would
just make all those CKQ bookmarks stop working. The %s would not be interpreted
unless it were found in a CKQ. Current CKQs in the bookmarks would point to URLs
with %s in them.

Perhaps the Bookmark CKQs could be deprecated. Every batch of release notes
after the CKQ-specific UI is avail would say "don't use CKQs in bookmarks any
more... they're going away" and then eventually they *would* go away.



(going on vacation soon, so may not reply to questions immediately)

Comment 3

16 years ago
... ... ...

when clicking on a bookmark that requires a parameter results in a prompt for a
parameter, the core complaint of this bug will be gone.

creating ui and code for whatever you are requesting would be significant bloat
both to code and ui and would be incomprehensible to everyone.
Component: Bookmarks → User Interface Design
Whiteboard: KILLME

Comment 4

16 years ago
Assignee: ben → mpt
QA Contact: claudius → zach

Comment 5

16 years ago
is there a bug number for that?

If so, droping this bug for that one sounds like a perfectly valid solution to me


Comment 6

16 years ago
That is bug 153534  "Bookmarking URLs containing %s should prompt the user for a
So I think that now this is just Wontfix.
Last Resolved: 16 years ago
Resolution: --- → WONTFIX

Comment 7

16 years ago
vrfy wont
Whiteboard: KILLME

Comment 8

16 years ago
No, the bug mentioned in comment 6 is about something else (filing bookmarks,
not clicking on existing ones). I couldn't find the right bug so I filed bug
175419, hoping it's not a dupe.


16 years ago
Component: User Interface Design → Browser-General
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.