Перенаправление пользовательской URI-схемы Google Chrome на JS

Question

В настоящее время я работаю над пользовательской URI-схемой (протоколом) в Google Chrome, и мне нужен метод для автоматизации некоторых испытаний (и разработки) этого протокола исключительно из браузера Chrome.

Например. Если ссылка перенаправления / привязки указывает на этот пример

testuri://thismessage/additionaldata

тогда я хотел бы перенаправить обратно в JS как-то. Т.е. с призывом сказать

function protocolMessage(data) { ... }

Я исследовал использование "navigator.registerProtocolHandler", но для этого необходимо использовать "web + testuri", что не вариант (если кто-то не знает настройки, которую можно использовать, чтобы отключить это).

Я исследовал использование пользовательского расширения Chrome для захвата URI под webNavigation, но он не захватывает ничего, кроме схем http(s). И я не вижу никаких функций, которые позволили бы мне зарегистрировать пользовательскую схему напрямую.

Дальнейшие исследования привели меня к попытке вызвать системное приложение (используя пользовательские uri-схемы, которые вызывают собственные исполняемые файлы), и это отчасти работает, но теперь я застрял в том, как перенаправить это сообщение обратно в javascript текущей страницы / вкладки.

Я также взглянул на NaCL (Pepper API's), но он также не позволяет регистрировать пользовательские схемы.

Я надеюсь на лучшее решение, чем вызов и возврат в браузер, но если нет, то может ли кто-нибудь пролить свет на хорошее надежное многоразовое решение?

Есть идеи? Заранее спасибо

Answer 1

Насколько мне известно, нет, к сожалению.

Все API Chrome работают с "поддерживаемыми схемами", и вы не можете добавить их.

web+custom: это также негибкое ограничение.

Если у вас есть системное приложение, вы можете поговорить с ним, предоставив в приложении сервер WebSocket или работая с Native Messaging.

Проблема с собственным обменом сообщениями заключается в том, что Chrome должен инициировать соединение с новым экземпляром собственного узла. Таким образом, вам нужно будет иметь возможность обрабатывать собственное приложение, вызываемое отдельно для обработки протокола и обмена сообщениями.