我正在爲Linux上的Google Chrome創建自定義協議處理程序。我的鏈接看起來是這樣的：爲什麼Linux上的Chrome針對未知協議顯示「外部協議請求」對話框？
<a href="myprotocol:someargument">Trigger my app with param</a>
我已經注意到，如果「myprotocol：」未註冊（不安裝我的應用程序），谷歌Chrome在Linux上顯示「外部協議請求」對話框，並嘗試使用XDG開：
而在其他操作系統，如Windows 10和OS X埃爾卡皮坦什麼，如果協議未註冊時顯示。
我還證實，Firefox可以在Windows，OS X和Linux上一致地處理未知協議 - 不會顯示任何內容。
Linux上的Chrome行爲對用戶來說是相當混亂的。
任何想法爲什麼Chrome在Linux上（我在Ubuntu 14.04上測試）與其他操作系統和Web瀏覽器的行爲不同？
問題是，如果Chrome缺少本地協議處理程序，那麼它想要使用在用戶環境中配置的處理程序。沒有兩個操作系統提供完全相同的API來啓動默認處理程序。在實際啓動它之前弄清楚這個程序會是什麼，甚至在Windows或Linux上都不是一個明確的API。
「Mac」和Windows實現最終都知道哪個外部應用程序最終對協議負責，因此能夠在不發出呼叫警告的情況下抑制未處理的呼叫。但是windows實現實際上是一個依賴於windows上現有版本的Windows註冊表觀察的混合物。這種類型的API違例在Linux上更加危險，因爲許多風格對相關設置工具的分支非常不同。
它實際上是considered a bug，Windows和OsX不會發出另一個警告，說他們什麼也沒有調用，所以如果你認爲這是正確的行爲，你可能想在這裏發表評論。
這裏是我的如何基於電流源上的3個系統工作觀察：
在Linux中，當您註冊協議處理程序與（窗口）系統，你做這樣的事情：
現在xdg-settings set default-url-scheme-handler myprotocol evolution.desktop
，應用演進負責你的協議，任何東西都可以撥打：
xdg-open myprotocol:...
現在打開這些鏈接的進化。其他操作系統具有類似的機制，但可能沒有外部程序作爲調用存根。
這是很好的和抽象的，並且knowing/saying the external app you are calling is xdg-open可以防止在linux實現中的複雜化。但這不完全是用戶可能想要的信息。獲取這些信息需要使用xdg-settings來代替，如果在此係統的某些版本中存在或將要有條件地覆蓋默認處理程序，則風險將不正確。
在Windows處理程序，顯然你可以去snooping around in the registry，然後作出一個猜測，以什麼調用API是要怎麼做。從技術上講，chrome必須這樣做，因爲它打開外部程序的方式是通過系統API，所以在警告中沒有像xdg-open這樣的外部存根。
在「陸委會」處理程序中，有一個適當的API來詢問該應用程序的特定的URL將推出，因此Chrome does，然後if the application name the empty string它可以生成警告之前完全掛斷電話。