这些 WebKit ASP 之间的差异：菜单修复

Question

我知道有大量关于 ASP:Menu 与 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 方法上使用，从而允许将其添加到母版页中，而无需继承的基页。