我们最近遇到了问题，因为自Firefox 4发布以来，ScrollPosition数据永远不会被发送给Firefox用户。这是由browsercaps文件仅指定Firefox 3.x的功能引起的。此问题的一个解决方案是更新每个服务器上的browsercaps文件，以及任何时候发布新版本的Firefox（或Chrome或其他）。好吧，在我们有机会解决这个问题之前，我们已经在Firefox 6上了，它看起来像是一场我们不想继续运行的竞赛。
事实证明，在母版页中设置Page.ClientTarget =“uplevel”（因此，对于所有内容，无条件）修复了我们特定的Firefox ScrollPosition问题。作为解决方案对此有什么负面影响？ Android浏览器的用户会遇到更糟糕的体验吗？他们现在只是下载不必要的大页面吗？我们有什么理由不这样做吗？
Page.ClientTarget的文档非常可怕：
uplevel，指定与Internet相当的浏览器功能 Explorer 6.0。
..似乎错了，或者至少是误导性的。它似乎是在IE6是最强大的浏览器的时候编写的。 “uplevel”是否真的意味着“假设浏览器能够胜任一切”或“像对待IE6一样对待它”？
答案 0 :(得分：3)
如果你想告诉WebForms有效地“裁员”然后设置Uplevel工作，虽然你想在早于主页面的Page_Init中这样做。此时，WebForms将假设每个人都是一个比你自己更新的浏览器。
答案 1 :(得分：1)
对于无法测试浏览器实际限制的服务器端兼容性，我更喜欢使用黑名单而不是白名单：如果浏览器不知道不支持功能X那么我假设它支持它。
您还可以将所有版本的浏览器列入黑名单，例如：没有版本的IE支持功能X）。这要求您在IE支持功能X后更新黑名单。
浏览器升级不应该破坏此方案。
答案 2 :(得分：0)
这不是“有什么缺点”问题的答案，但是：
您可以在browsercaps文件中的浏览器版本检测中使用正则表达式。
例如，2011年11月13日，Microsoft发布了ASP.NET 4.0更新，将IE10添加到高级列表中（并修复了位于ie.browser中的\Windows\Microsoft.NET\Framework\v4.0.30319\Config\Browsers文件中的错误）。他们有一个只检查单位数主要版本的正则表达式，但在补丁之后，任何IE版本＆gt; = 6将被视为高级版。
改变之前：
<capability name="majorversion" match="[6-9]" />
改变之后：
<capability name="majorversion" match="[6-9]|[1-9]\d+" />
我猜你不再遇到这个问题了，因为至少截至2011年10月26日，firefox指令还使用正则表达式来检测高级版本＆gt; = 3 :(来自{{1}文件）
firefox.browser但是如果你还有probs，那就在<browser id="Firefox3" parentID="Firefox">
<identification>
<capability name="majorversion" match="^[3-9]|[1-9]\d+" />
</identification>
<capabilities>
<capability name="javascriptversion" value="1.8" />
<capability name="supportsMaintainScrollPositionOnPostback" value="true" />
</capabilities>
</browser>
文件中使用一个前瞻性的正则表达式（一个没有“早期补丁中的”单数字主要版本“的错误）