So I have a modestly popular Safari extension that enables keyword search from the address bar. This extension relies on an event called
beforeNavigate, which is triggered whenever a user tries to load a url. This event has been available for extensions since Safari 5.1.
The event is kind of tricky to work with for what I’m trying to do, since it is triggered after Safari has tried to parse whatever text was entered in the address bar into a URL. This means that when a user types g monkey, the event provides the URL
http://g%20monkey/, making parsing harder than it should be, especially for the default keywordless search (which is Googles “I am feeling lucky”). In addition the search phrase a user enters cannot contain a colon symbol, as that causes Safari to show an error page before the event is triggered.
These are minor annoyances but work-aroundable. The real problem is Safari 5.2, which unifies the search bar and the address bar into a single text field that is similar to (but much less capable than) the Omnibar in Chrome. What now happens is that anything that doesn’t look like a URL is turned into a web search, before the
beforeNavigate event is triggered. That means that the data sent along with the event looks like
http://google.com?q=g%20monkey. This could still be parseable by the extension, but it is impossible to know whether the user entered it as a keyword search or actually want to search google for “g monkey”.
Needless to say this regression makes my extension broken and useless in Safari 5.2. I have reported this issue to Apple, and suggested three possible ways to fix it, in order of preference:
Fingers are crossed.
My name is Arne Martin Aurlien and I write stuff here sometimes.
Here’s a few things I have made: