[Greasemonkey] Handling keyword: URLs

[Aaron Boodman]

Yeesh. This really smells like a Mozilla bug to me. It seems like the
method in the UI you used to get to the Google search results page
(for instance) should be completely transparent to content.

What would happen if Google search results had javascript which
checked it's own location.href property? It looks like it would be
incorrect.

Anyway, that's good info to have. Thanks for the note.

-- 
Aaron

On 8/12/05, Dave Land <land at aol.com> wrote:
> Howdy,
> 
> I set the "keyword.URL" preference to "http://www.google.com/search?q="
> to eliminate the space-wasting search box. In effect, I'm overloading
> the location bar to serve as both a "Go" and a "Search" box.
> 
> When I type something like "greasemonkey bugs" in the location box, it
> is magically converted into "keyword:greasemonkey%20bugs" and a lovely
> Google page appears.
> 
> Well, mostly lovely...
> 
> GM scripts that act on Google pages don't fire, because the URL,
> "keyword:greasemonkey%20bugs", doesn't have "google" in it. Also,
> scripts that make assumptions about the value of location.href (such as,
> that it is an "http[s]://" URL) may fail.
> 
> To address the first issue, I oadd "keyword:*" to the Included Pages
> settings for Google-targeted scripts that I install. This works for me
> because I have set "keyword.URL" as I have. It might not work if you use
> some other keyword URL. Hence, it might have been a mistake for me to
> code "// @include keyword:*" in my "Google defs from dictionary.com"
> script, which returns us to the thrilling days of yesteryear, when the
> definition links at the top of Google results went to my favorite
> dictionary site, instead of answers.com.
> 
> For scripts that rely on location.href containing an http[s]:// URL, I
> get the value of the keyword.URL preference when location.href begins
> "keyword:".
> 
> For instance, I modified Stuart Langridge's "css-signature.user.js" to
> add the signature "www-google-com" to my "keyword:"-obtained pages.
> This one works regardless of your personal "keyword.URL" setting,
> because that's exactly where I obtain the proper URL:
> 
> Original body of "css-signature.user.js" (Zen-like in its simplicity):
> 
> (function() {
>    if (document.body && document.body.id == '')
>      document.body.id = location.host.replace(/\./g,'-').toLowerCase();
> })();
> 
> Modified version:
> 
> (function() {
>    if (document.body && document.body.id == '') {
>      if (location.protocol == 'keyword:' ) {
>        // On "keyword:" pages, ...
>        try {
>          // get permission to read preferences
> 
> netscape.security.PrivilegeManager.enablePrivilege('UniversalPreferences
> Read');
>          var kwu = navigator.preference('keyword.URL');
>          document.body.id =
> kwu.split('/')[2].replace(/[\.:]/g,'-').toLowerCase()
>        } catch (e) {
>          // No permission
>          GM_log('No permission to read "keyword.URL" preference.');
>        }
>      } else {
>        // On all other pages, (usually "http[s]://"), ...
>        document.body.id =
> location.host.replace(/[\.:]/g,'-').toLowerCase();
>      }
>    }
> })();
> 
> OK, so it's a little gunky that permission needs to be obtained to read
> the keyword.URL preference, but I think the browser only has to ask the
> user once.
> 
> This might helpful to add to the DiG pattern 4.18: "Getting the current
> domain name".
> 
> Dave
> 
> _______________________________________________
> Greasemonkey mailing list
> Greasemonkey at mozdev.org
> http://mozdev.org/mailman/listinfo/greasemonkey
>