Use GlimmerBlocker keywords in Google Quick Search Box
Oct 05, '09 07:30:03AM • Contributed by: Andrew J Freyer
Oct 05, '09 07:30:03AM • Contributed by: Andrew J Freyer
GlimmerBlocker is a fantastic proxy-based ad remover and content filter for Mac. The biggest benefit is that since it does not use InputManagers, it works perfectly with Snow Leopard. One of the best features of GimmerBlocker is keyword expansion (akin to Keywurl). Type hulu house in the address bar, and GimmerBlocker directs Safari to Hulu, executing a search for House.
However, for me, quick web searches like this usually start from the Google Quick Search Box. This hint allows all GlimmerBlocker keyword expansions to be initiated from the Google Quick Search Box, by writing two rules in GlimmerBlocker.
Here is the GB XML for the two rules:
Copy the above code, select a filter, and paste it into the "Rules in [this filter]" panel of the GlimmerBlocker preference pane.
Essentially, the first rule looks for the client=qsb-mac tag in a Google search, since that flag is appended only for Google Quick Search Box queries. It then strips everything but the actual query and resubmits to Safari:
Original URL: www.google.com/search?client=qsb=mac....q=key%20whatever%20else
Modified URL: http://key%20whatever%20else/
Usually, this would return a "Page not found" error, since that is obviously a poorly-formatted URL. Except that in this case, GlimmerBlocker recognizes this as matching the keyword key, and then follows whatever rule is associated with key.
The second rule is a catchall for poorly-formatted, multi-word addresses submitted to the Safari address bar. It (like Firefox does natively) submits these bad queries to Google.
Original URL: http://NOkey%20whatever%20else
Modified URL: http://google.com/search?q=NOkey%20whatever%20else
[robg adds: I haven't tested this one.]
However, for me, quick web searches like this usually start from the Google Quick Search Box. This hint allows all GlimmerBlocker keyword expansions to be initiated from the Google Quick Search Box, by writing two rules in GlimmerBlocker.
Here is the GB XML for the two rules:
<?xml version="1.0" encoding="UTF-8"?>
<glimmerblocker-rules>
<rule priority="2" type="request" path="/" path-type="is">
<comments><![CDATA[Google Search bad requests.]]></comments>
<request language="js" version="1"><![CDATA[var h =
gb.request.urlHost;
if (h.match(/([%]+)/) ) {
gb.response.sendRedirect("http://www.google.com/search?q=" + h);
}]]></request>
</rule>
<rule priority="2" type="request" host="www.google.com" host-type="is"
query="&client=qsb-mac" query-type="contains">
<comments><![CDATA[Forward QSB Quick Search keywords]]></comments>
<request language="js" version="1"><![CDATA[var m =
gb.request.urlQuery.match(/&q=([^&]+)&client=qsb-mac/);
if (m) {
var newURL ="http://" + m[1];
gb.response.sendRedirect(newURL);
}
else {
gb.response.sendText("GlimmerBlocker recognized a request from Google QSB,
but search failed to match URL: '" +
gb.htmlEncode(gb.request.urlQuery) + "'");
}]]></request>
</rule>
</glimmerblocker-rules>Essentially, the first rule looks for the client=qsb-mac tag in a Google search, since that flag is appended only for Google Quick Search Box queries. It then strips everything but the actual query and resubmits to Safari:
Original URL: www.google.com/search?client=qsb=mac....q=key%20whatever%20else
Modified URL: http://key%20whatever%20else/
Usually, this would return a "Page not found" error, since that is obviously a poorly-formatted URL. Except that in this case, GlimmerBlocker recognizes this as matching the keyword key, and then follows whatever rule is associated with key.
The second rule is a catchall for poorly-formatted, multi-word addresses submitted to the Safari address bar. It (like Firefox does natively) submits these bad queries to Google.
Original URL: http://NOkey%20whatever%20else
Modified URL: http://google.com/search?q=NOkey%20whatever%20else
[robg adds: I haven't tested this one.]
•
[5,521 views]
