5

I have an issue with Chrome. The web app sends a number of protocol handler calls to an application, installed on the clients computer, using a Iframe element.

<iframe src="myprotocol://guid"></iframe>

It works on Ie and Firefox. On chrome it works on the first call only. The second call requires the user to be active on the computer and working with Chrome.

Is there any way to accomplish this? maybe using a Chrome plug-in?

bafla
  • 1,029
  • 1
  • 10
  • 14
  • [This issue on IOS](https://bugs.chromium.org/p/chromium/issues/detail?id=348640) may explain this but the same happens on windows. – Serxipc Feb 27 '17 at 11:29

1 Answers1

0

You likely need to reset your protocol handler configuration. Failing that is the handler actually executing successfully, a crash in the handler may just cause chrome to drop it.

Debug both ends if you can.

https://vsee.zendesk.com/hc/en-us/articles/209804153-How-to-Reset-Protocol-Handler-on-Chrome-VSee-doesn-t-launch-from-waiting-room-

War
  • 8,539
  • 4
  • 46
  • 98
  • The handler is not blocked, it launches ok on the first call but it fails if we try to launch it again on the same page from javascript, without user intervention – Serxipc Mar 06 '17 at 10:46
  • I believe that's by design, to prevent certain security flaws (e.g. the link you posted to Apple where people are using this stuff to spam load apps). – War Mar 06 '17 at 10:48
  • I'm sure that it's by design, but I haven't found any piece of documentation about it. – Serxipc Mar 06 '17 at 11:48
  • 1
    Anything on this front is going to be a bit of an ugly hack ... look at all that hassle Microsoft had because ActiveX could do this type of thing ... people are very protective of their sandboxes and like them to stay that way so reaching outside of the browser is a "problem area" by design. Not helpful I know but it might be worth rethinking your solution. – War Mar 06 '17 at 12:37