Custom "Open Item" script for browser

It would be very handy to activate/focus an existing browser tab instead of just letting Safari handle opening the linked URL. Safari (at least in 12.1.2), switches to the existing tab as desired, but reloads it. Ideally it would just switch to the existing tab without the reload. An example use case for this would be long web-based documents (Google docs, Dropbox Paper, etc.). When Safari reloads these, the scroll position is lost (in addition to the time wasted finding your previous position in the document, time is also lost waiting for the reload itself to occur). So, yes, this is using Hook beyond just a “linker” and also using it as an app switcher.

The desired Safari behavior is achievable through Apple Script but I’m running into trouble getting it to work as a Custom Open Item script.

Is a custom Open Item script possible with browsers? I notice Chrome, Firefox and Safari don’t have this script out-of-the-box, indicating that macOS is handling the call.

If it is possible, what should be used as the Scheme? I’ve tried web, browser, safari and url with no success. (I notice that Apple Mail, Airmail and MailMate all used the email Scheme so I was thinking it might need to be something specific but don’t think I’ve guessed correctly.

For testing purposes, I entered a simple Open Item script that just opens an alert dialog box with a “testing” string. However I don’t get an alert when opening a linked Safari URL via Hook. Safari just goes ahead and reloads the page in the existing tab (or opens a new tab if it doesn’t exist). It seems like my Open Item script is being bypassed. Any pointers? Thanks in advance!

1 Like

To get a custom opener to run for a standard URL you’ll need to:

  1. Enter something unique as the scheme for Safari — doesn’t matter what as long as it doesn’t conflict.
  2. Make a new link in Hook — old links won’t be converted.

If you’ve done both of those you should be able to get that alert.


Thanks for the tips! I didn’t see either of those in the docs, however my custom Open Item script still doesn’t seem to run.

I’m using safariurl which seems unique. It doesn’t appear in any other app under the Scripts tab in Prefs.

Definitely didn’t know this was required. I tried deleting and relinking to a couple of different sites (just to rule out an issue with a certain domain) but I still get the normal Safari loading behavior and not my Applescript alert.

I tried restarting Hook and the apps involved (Safari, Word) as well just in case but no joy. Am I missing anything else? If it helps, here’s a screenshot of my current Safari script setup:

Thanks again! It is really cool that Hook has the foresight to allow overriding the default behavior this way! Very powerful.

1 Like

The scheme has to match the URL returned by the Get Address script. If the scheme is safariurl, Get Address needs to return safariurl:// instead of

The Get Address script will need to change the scheme of the URL it returns. Try something like this:

tell application "Safari"
	set d to first item of documents
	set u to URL of d
	set AppleScript's text item delimiters to {"://"}
	return "safariurl://" & text item 2 of u
end tell

Ah, I had always assumed Hook prepended the scheme to whatever Get Address returned.

Is there any benefit to not doing that or could this perhaps be a feature request?

On behalf of CogSci Apps, thank you :slight_smile: . While the tool is designed to be helpful for all knowledge workers and higher ed students, we are also particularly determined to ensure that it solves all the “meta-access problems” developers face. E.g., Hook can generate links to files that are in repositories (like Git, SVN and Dropbox) that work across users and even if the files are moved to different folders. When I write technical documentation (something I do a lot of here at CogSci Apps), I include Hook links (in Markdown) in the “Related Documentation” section. I also often include a Hook links folder in my tech docs, so that readers can quickly navigate. and of course you can share links to code as well (which you can include in code comments , emails, etc.) Hook’s DB is not encrypted. No “lock in”. We have already announced on this forum that Hook itself will be automatable. We will publish several documents later about how Hook is friendly to developers.

(More generally: Hook really is an example of a tool that is designed to solve problems that we ourselves faced – as developers and as knowledge workers. In fact, it is part of our longstanding research projects on the meta-access problem (navigating related information). The term meta-access problem comes from my first Cognitive Productivity book. Previous work on “personal information management” had not adequately characterized the problems (e.g., the prominent metaphor in the literature still is curation — yet clearly whereas some curation/organization is required, people often CANNOT curate/organize, because the info is in shared repositories or on the web.) We will also publish papers about this in human-computer interaction. But I digress.)

1 Like

Thanks for clearing this up! Your guidance helped me make it work! I’ll clean it up and post in the scripts category (and link to it in this thread) in case anyone else would prefer this behavior as well.

I definitely did not understand the concept from reading the scripting docs several times.

It is confusing the docs have the correct url format (e.g. scheme://document-identifier) but the Scripts dialog in the app shows the format on the Open Item tab: Hook://[scheme]/document-identifer. The Get Address script doesn’t include Hook and :// is in the wrong place.

Overall, it seems it would also help to understand custom scripts if the docs started with a detailed overview of the process Hook uses to link items. E.g. When you press ⌘+C, Hook calls the Get Address script which must return the url in the format…

Is there a place on the forum we should suggest doc enhancements?

Great question. I’m just starting out with Hook so I don’t have a ton of existing links but if I’d have been using it for awhile, the thought of having to go relink everything involving the app (Safari, in this case) because it now has to use a custom URL scheme, is scary.

There has been mention the roadmap may include some ability to access the Hook database. I wonder if this would allow bulk updates to links of a certain type. Of course, back to your original point, if the custom Open Item script didn’t rely on a custom URL scheme a bulk update wouldn’t even be necessary.

Thanks for the feedback. I’ve added an action in our issue tracking system to improve the documentation in line with your suggestion. We are planning significant updates to match upcoming enhancements of Hook itself.

thanks for asking. I’ve edited the name and description of the Latest Site Feedback (About the Forum and documentation) topics - Hook Productivity Forum category to make it clear that that’s the place to make suggestions about the website, online documentation and forum.

Thanks for the clarification, @LucB! I’ll definitely add anything I can think of to that category.

@LucB, any thoughts on putting the other topic here (not requiring a custom URL scheme when you just want to change the Open Item behavior) on the roadmap?

In the case of the browser, I’m assuming Hook is just sending the URL to the system to handle opening. It would be amazing if Hook could detect the Open Item script and use that instead of relying only on a custom URL scheme. I realize this would probably require a preference to set the browser you’d like Hook to use to open web URLs (assuming it can’t get the default from macOS programmatically) so it could determine the script to use but totally worth it!

I think Graham will follow up with more information, but some thoughts here

As long as an application registers its own scheme, the URL returned from getAddress will not be prepended with “hook” scheme.

I think the first order of business will be for the Script tab labels to be updated. The Hook://" label makes it look like the app is specifying a hook:// protocol . The uppercase is meant to signal that this is about Hook (app) not hook:// protocol.

Hook’s modus operandus is that if an application has its own registered (custom) scheme, getAddress should just return the URL with custom scheme. This makes the link work even without Hook. We use hook:// protocol as little as possible.

that is the case. In fact, often Hook is not even the proxy. The user can do “Copy as Link” in Hook, and paste that in a document or note. Then when the user activates it, whatever app is in use will pass the request to the OS. e.g., here is a link to an OmniFocus task via“Copy as Link” : omnifocus:///task/cbA0gCik-Zt. Whether you activate that link in the Hook window or in say TextEdit, it will be passed to OmniFocus (assuming OmniFocus is registered to handle it.)

That is probably quite redundant information for you, but maybe helpful for some of the other readers.

Now finally getting to your point. There is a Favorite apps pane. That currently only has mail apps. Mail apps are there due to a limitation in macOS that Hook allows users to get around. We considered something similar for .txt files. This would override general macOS preferences. We haven’t gone there so far to keep it simple, and again Hook is not always a proxy in activating links. But that pane can in principle have other apps. This explains why we put this in its own pane.

We have a number of significant feature sets to introduce, and a very long list of smaller refinements. So we’re weighing them.