为所有页面设置Page.ClientTarget =“uplevel”有什么缺点?

时间:2021-11-08 15:54:18

We've run into problems recently because as of Firefox 4's release, ScrollPosition data never gets sent to Firefox users. This is caused by the browsercaps file only specifying capabilities for Firefox 3.x. One solution to this problem is to update the browsercaps file on every server, and any time a new version of Firefox (or Chrome, or whatever) is released. Well, before we've even had a chance to address this problem, we're already on Firefox 6, and it just seems like a race that we don't want to keep running.

我们最近遇到了问题,因为自Firefox 4发布以来,ScrollPosition数据永远不会被发送给Firefox用户。这是由browsercaps文件仅指定Firefox 3.x的功能引起的。解决此问题的一个方法是更新每台服务器上的browsercaps文件,以及任何时候发布新版本的Firefox(或Chrome或其他)。好吧,在我们甚至有机会解决这个问题之前,我们已经在Firefox 6上,它看起来像是一场我们不想继续运行的竞赛。

It turns out that setting Page.ClientTarget = "uplevel" in the master page (so, for everything, unconditionally) fixes our specific Firefox ScrollPosition issue. What are the negative consequences to this as a solution? Are users of Android browsers going to have a worse experience? Are they simply going to be downloading unnecessarily larger pages now? Is there any reason we shouldn't do this?

事实证明,在母版页中设置Page.ClientTarget =“uplevel”(因此,无论如何,无条件地)修复了我们特定的Firefox ScrollPosition问题。作为解决方案,对此有什么负面影响? Android浏览器的用户会遇到更糟糕的体验吗?他们现在只是下载不必要的大页面吗?我们有什么理由不这样做吗?

The documentation for Page.ClientTarget is pretty scary:

Page.ClientTarget的文档非常可怕:

uplevel , which specifies browser capabilities equivalent to Internet Explorer 6.0.

uplevel,指定与Internet Explorer 6.0等效的浏览器功能。

.. and seems wrong, or at least misleading. It seems like it was written at a time when IE6 was the most capable browser. Does "uplevel" really mean "assume the browser is capable of everything" or "treat it like you'd treat IE6"?

..而且似乎是错误的,或者至少是误导性的。它似乎是在IE6是最强大的浏览器的时候编写的。 “uplevel”是否真的意味着“假设浏览器能够胜任一切”或“像对待IE6一样对待它”?

3 个解决方案

#1


3  

If you want to tell WebForms to effectively "lay off" then setting Uplevel works, although you want to do it in Page_Init which is earlier than the Master Page. At this point, WebForms will assume everyone is a newer browser than you're on your own.

如果你想告诉WebForms有效地“裁员”,那么设置Uplevel是有效的,尽管你想在早于Master Page的Page_Init中进行。在这一点上,WebForms将假设每个人都是一个比你自己更新的浏览器。

#2


1  

For server-side compatibility, which can't test the browser's actual limitations, I prefer using a blacklist instead of a whitelist: if a browser isn't known to not support feature X then I assume it supports it.

对于无法测试浏览器实际限制的服务器端兼容性,我更喜欢使用黑名单而不是白名单:如果不知道浏览器不支持功能X,那么我认为它支持它。

You can also blacklist all versions of a browser, e.g. no version of IE supports feature X). this requires you to update the blacklist once IE does support feature X.

您还可以将浏览器的所有版本列入黑名单,例如没有版本的IE支持功能X)。这要求您在IE支持功能X后更新黑名单。

Browser upgrades shouldn't break this scheme.

浏览器升级不应该破坏这个方案。

#3


0  

This is not an answer to the "what are the drawbacks" question, but:

这不是“有什么缺点”问题的答案,但是:

You can use regular expressions in the browser version detection within the browsercaps files.

您可以在browsercaps文件中的浏览器版本检测中使用正则表达式。

For example, on November 13, 2011 Microsoft released an update for ASP.NET 4.0 that added IE10 to the uplevel list (and fixed a bug in the ie.browser file, located in \Windows\Microsoft.NET\Framework\v4.0.30319\Config\Browsers). They had a regular expression that only checked for single-digit major version, but after the patch any IE version >= 6 will be considered uplevel.

例如,在2011年11月13日,Microsoft发布了ASP.NET 4.0更新,将IE10添加到高级列表中(并修复了位于\ Windows \ Microsoft.NET \ Framework \ v4.0.30319中的ie.browser文件中的错误) \ CONFIG \浏览器)。他们有一个只检查单位数主要版本的正则表达式,但在补丁之后,任何IE版本> = 6都将被视为高级版本。

Before the change:

在改变之前:

<capability name="majorversion" match="[6-9]" />

After the change:

改变后:

<capability name="majorversion" match="[6-9]|[1-9]\d+" />

I'm guessing you are not running into this problem any more, because at least as of 26 October 2011, the firefox directive also uses a regex to detect as uplevel versions >= 3: (from the firefox.browser file)

我猜你不再遇到这个问题了,因为至少截至2011年10月26日,firefox指令还使用正则表达式检测为高级版本> = 3 :(来自firefox.browser文件)

<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>

but if you are still having probs, just use a forward-thinking regex (one that does not have a "single digit major version" bug like in earlier patches) in the firefox.browser file

但是如果你还有probs,那就在firefox.browser文件中使用一个前瞻性的正则表达式(一个没有“早期补丁中的”单数字主要版本“的错误)

#1


3  

If you want to tell WebForms to effectively "lay off" then setting Uplevel works, although you want to do it in Page_Init which is earlier than the Master Page. At this point, WebForms will assume everyone is a newer browser than you're on your own.

如果你想告诉WebForms有效地“裁员”,那么设置Uplevel是有效的,尽管你想在早于Master Page的Page_Init中进行。在这一点上,WebForms将假设每个人都是一个比你自己更新的浏览器。

#2


1  

For server-side compatibility, which can't test the browser's actual limitations, I prefer using a blacklist instead of a whitelist: if a browser isn't known to not support feature X then I assume it supports it.

对于无法测试浏览器实际限制的服务器端兼容性,我更喜欢使用黑名单而不是白名单:如果不知道浏览器不支持功能X,那么我认为它支持它。

You can also blacklist all versions of a browser, e.g. no version of IE supports feature X). this requires you to update the blacklist once IE does support feature X.

您还可以将浏览器的所有版本列入黑名单,例如没有版本的IE支持功能X)。这要求您在IE支持功能X后更新黑名单。

Browser upgrades shouldn't break this scheme.

浏览器升级不应该破坏这个方案。

#3


0  

This is not an answer to the "what are the drawbacks" question, but:

这不是“有什么缺点”问题的答案,但是:

You can use regular expressions in the browser version detection within the browsercaps files.

您可以在browsercaps文件中的浏览器版本检测中使用正则表达式。

For example, on November 13, 2011 Microsoft released an update for ASP.NET 4.0 that added IE10 to the uplevel list (and fixed a bug in the ie.browser file, located in \Windows\Microsoft.NET\Framework\v4.0.30319\Config\Browsers). They had a regular expression that only checked for single-digit major version, but after the patch any IE version >= 6 will be considered uplevel.

例如,在2011年11月13日,Microsoft发布了ASP.NET 4.0更新,将IE10添加到高级列表中(并修复了位于\ Windows \ Microsoft.NET \ Framework \ v4.0.30319中的ie.browser文件中的错误) \ CONFIG \浏览器)。他们有一个只检查单位数主要版本的正则表达式,但在补丁之后,任何IE版本> = 6都将被视为高级版本。

Before the change:

在改变之前:

<capability name="majorversion" match="[6-9]" />

After the change:

改变后:

<capability name="majorversion" match="[6-9]|[1-9]\d+" />

I'm guessing you are not running into this problem any more, because at least as of 26 October 2011, the firefox directive also uses a regex to detect as uplevel versions >= 3: (from the firefox.browser file)

我猜你不再遇到这个问题了,因为至少截至2011年10月26日,firefox指令还使用正则表达式检测为高级版本> = 3 :(来自firefox.browser文件)

<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>

but if you are still having probs, just use a forward-thinking regex (one that does not have a "single digit major version" bug like in earlier patches) in the firefox.browser file

但是如果你还有probs,那就在firefox.browser文件中使用一个前瞻性的正则表达式(一个没有“早期补丁中的”单数字主要版本“的错误)