Difference between these WebKit ASP:Menu fixes

Question

I know there are a ton of posts on the ASP:Menu vs. WebKit issue in general, but I cannot find one that answers my question.

I frequently see people recommending two different methods to fix the problem with ASP:Menus in Apple WebKit browsers (i.e., Chrome, Safari). But which is actually better? What is the difference between these two actions besides the targeted user agent? The only difference I found is that the second will also work on the Page_Load event. I assume one is objectively superior to the other, but I do not know the difference between them. How do each of them work?

Both go in the Page_PreInit() method of the base page.

1. Clear the browser adapters.

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

2. Change the client target.

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

The default user agent for Google Chrome is as follows. It contains both Safari and WebKit, so I doubt the targeted user agent is a significant difference.

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

Alright, I have "solved" this on my own because no one else apparently knows. The actual answer is that ASP.NET recognizes browsers using WebKit as "downlevel" browsers, meaning they are supposedly incapable of processing modern HTML or JavaScript. To compensate, ASP.NET renders the menu markup differently using "Adapters."

In situation 2. (changing the client target), the client is forced to be recognized as an "uplevel" browser. Consequentially, the menu is rendered normally, as it would be for Internet Explorer or FireFox.

In situation 1. (clearing the browser adapters), the client is still seen as downlevel and an adapter is inserted in order to compensate for the supposedly old browser, but before it can be used, all of the adapters are flushed out.

Thus, I conclude that technically method 2. is better because

1. It efficiently stops downlevel browser compensation before an adapter is used.
2. It correctly recognizes the browser as uplevel, in case that fact is used elsewhere in the application.
3. It does not clear the adapters, which could legitimately be used for another purpose by the user.
4. As I said in my problem statement, it can be used on the Page_Load method rather than the Page_PreInit method, thereby allowing it to be added into a Master Page without need of an inherited base page.