Eu tenho o mesmo problema e não sei como evitar o erro. No entanto, se você puder conviver com a mensagem de erro feia que faz spam no console, você pode contornar:
No momento em que o erro é lançado, o _on_activate_uri foi executado, portanto, tudo o que você gostaria de fazer lá (impressão, no seu exemplo) deveria ter acontecido. Certamente funciona assim para mim.
Basicamente, escolhendo o esquema URI para os recursos do modelo sabiamente, podemos emular HIDE_DASH ou o comportamento padrão de fallback (use o aplicativo instalado adequado para o esquema uri).
No meu caso, e no seu exemplo, queremos o comportamento HIDE_DASH. Quando o erro é lançado, aparentemente a unidade tenta lidar com a situação abrindo o URI com um aplicativo adequado. Assim, para fazer com que ele se comporte como em HIDE_DASH, basta nos certificarmos de fornecer aos URIs de recursos do nosso modelo um esquema que nenhum aplicativo instalado possa manipular. No meu caso, isso faria com que os URIs começassem com "pidgin-lens: //".
Se os seus URIs começarem com "http: //", o navegador será aberto após _on_activate_uri ser executado, para que o comportamento (NOT_HANDELED / GOTO_DASH_URI) seja facilmente emulado também.
SHOW_DASH provavelmente não pode ser emulado.