Il problema è in realtà che se Chrome manca di un gestore di protocollo locale, allora vuole usare il gestore configurato nell'ambiente dell'utente. Nessun due SO fornisce esattamente la stessa API per avviare un gestore predefinito. Capire cosa sarebbe questo programma prima di lanciarlo in realtà non è nemmeno un'API chiara su Windows o Linux.
Entrambe le implementazioni "Mac" e Windows finiscono per sapere quale applicazione esterna è in definitiva responsabile del protocollo e quindi sono in grado di sopprimere le chiamate non gestite senza emettere un avviso di chiamata. Ma l'implementazione di Windows è in realtà un kludge che si basa su osservazioni del registro di Windows su versioni esistenti su Windows. Questo tipo di violazione dell'API è più pericoloso su Linux, dove molti sapori hanno forchette molto diverse degli strumenti delle impostazioni correlate.
In realtà è considered a bug che Windows e OsX non emettono un avviso alternato che non hanno chiamato nulla, quindi si consiglia di commentare qui se si pensa che sia il comportamento giusto.
Ecco la mia osservazione di come il lavoro di 3 sistemi in base alla sorgente di corrente:
Linux
In Linux, al momento della registrazione gestori di protocollo con il sistema (finestra), si fa qualcosa di simile:
xdg-settings set default-url-scheme-handler myprotocol evolution.desktop
Ora, l'evoluzione applicazione è responsabile per il protocollo e tutto può chiamare:
xdg-open myprotocol:...
Per ora aprire l'evoluzione su questi collegamenti. Gli altri SO hanno meccanismi simili, ma potrebbero non avere un programma esterno come lo stub della chiamata.
Questo è bello e astratto e knowing/saying the external app you are calling is xdg-open impedisce molte complicazioni nell'implementazione di Linux. Ma non è esattamente l'informazione che l'utente probabilmente vuole. Ottenere tali informazioni richiederebbe invece l'uso di xdg-settings e rischia di essere errato se c'è o sarà sempre un modo per sovrascrivere condizionalmente il gestore predefinito in alcuni ambienti di questo sistema.
di Windows
Nel gestore di Windows, a quanto pare si può solo andare snooping around in the registry e poi formulare un'ipotesi su ciò che chiama l'API sta per effettivamente fare. Tecnicamente, Chrome deve fare questo poiché il modo in cui apre i programmi esterni è attraverso un'API di sistema, quindi non c'è uno stub esterno come xdg-open a cui fare riferimento nell'avviso.
Mac
Nel gestore "mac", v'è un'API corretta per chiedere l'applicazione tuo URL specifico lancerà, in modo da cromo does, allora if the application name the empty string si può cadere completamente la chiamata prima di generare l'avviso.
