這些WebKit ASP之間的差異：菜單修復

Question

我知道ASP上有大量的帖子：菜單和WebKit問題，但我找不到一個回答我的問題。

我經常看到有人推薦兩種不同的方法來解決Apple WebKit瀏覽器（即Chrome，Safari）中ASP:Menu的問題。但哪個更好？這兩種行爲除了目標用戶代理之外還有什麼區別？我發現唯一的區別是第二個也會在Page_Load事件中起作用。我假設一個客觀上優於另一個，但我不知道它們之間的區別。他們每個人如何工作？

都進入基頁的Page_PreInit()方法。

1.清除瀏覽器適配器。

if (Request.UserAgent.Contains("AppleWebKit")) 
{ 
    Request.Browser.Adapters.Clear(); 
} 

2.更改客戶目標。

if (Request.UserAgent.Contains("Safari")) 
{ 
    Page.ClientTarget = "uplevel"; 
} 

Google Chrome的默認用戶代理程序如下所示。它包含Safari和WebKit，所以我懷疑目標用戶代理是一個顯着的差異。

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/525.13 (KHTML, like Gecko) Chrome/0.X.Y.Z Safari/525.13. 

Answer 1

好吧，我已經「自己解決了」，因爲沒有其他人明顯知道。實際的答案是，ASP.NET將使用WebKit的瀏覽器識別爲「低級」瀏覽器，這意味着它們被認爲無法處理現代HTML或JavaScript。爲了補償，ASP.NET使用「適配器」以不同的方式呈現菜單標記。

在情況2.（更改客戶端目標）時，客戶端被迫識別爲"uplevel"瀏覽器。因此，菜單正常顯示，就像Internet Explorer或FireFox一樣。

在情況1.（清除瀏覽器適配器），客戶端仍然被視爲低級別，並且插入適配器以彌補舊式瀏覽器，但在可以使用之前，所有適配器被衝出。

因此，我的結論是技術上方法2.更好，因爲

1. 它使用的適配器之前有效停止下級瀏覽器補償。
2. 它正確地將瀏覽器識別爲上層，以防事實上在應用程序的其他地方使用。
3. 它不清除適配器，它可以合法地被用戶用於其他目的。
4. 正如我在我的問題陳述中所說的那樣，它可以在Page_Load方法上使用，而不是在Page_PreInit方法中使用，從而允許將它添加到主頁面中而不需要繼承的基頁面。