How should we handle IE compatibility mode?

[efouts]

How should we handle IE compatibility mode?

The date for the support change announced here is approaching. I use the analysis of UAs to determine support and understanding what version of IE end users are running in addition to what version is being emulated is crucial.

Currently compatibility mode user agent strings such as these from IE 11 are parsed as 10 and 9.

Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.3; Trident/7.0) Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.3; Trident/7.0)

Does it make sense to add the idea of engines like @commenthol has in his ua-parser2 or are there other ideas?

Some guidance before spending time on PR is appreciated.

[efouts]

\cc @dmolsen @tobie

[tobie]

\cc @elsigh

[elsigh]

I used to do client-side detection to determine what version of IE the browser was acting as regardless of what it said in the UA string. IE Compat mode is just hell. If you have a simple PR that you think solves the isse, can you describe how it would work? I suspect @commenthol has a good solution and if it works for you use that? To the extent that it's crucial for you - can you describe how or why too? For me it had to do with dealing with browser rendering bugs and needing to code branch to deal with them. I'm not sure uap needs to solve that particular problem.

[efouts]

For my enterprise product, we maintain a list of supported browsers. When making decisions around dropping support, it would be helpful to understand which versions are truly being ran rather than seeing inflated numbers around previous versions of IE. I have to imagine this is a pretty common topic when making support decisions.

It seems its just a matter to doing additional parsing into the trident token from the UA string (source).

When the F12 developer tools are used to change the browser mode of Internet Explorer, the version token of the user-agent string is modified to appear so that the browser appears to be an earlier version. This is done to allow browser specific content to be served to Internet Explorer and is usually necessary only when websites have not been updated to reflect current versions of the browser.

When this happens, a Trident token is added to the user-agent string. This token includes a version number that enables you to identify the version of the browser, regardless of the current browser mode.

In general, public websites should rely on feature detection, rather than browser detection, in order to design their sites for browsers that don't support the features used by the website. For more info, see Detecting Internet Explorer More Effectively.

Sites that rely on user-agent strings to generate visitation statistics should update their algorithms to account for the Trident token; otherwise, visitation metrics might not accurately reflect the true composition of browser usage.

Im interested in thoughts around how to output the information given that this is specific to a single family of browser. New field, reuse an existing one, etc?

[efouts]

Maybe a good question to ask is, should this parser return the version of IE running or the one being emulated or both?

[efouts]

In terms of statistics, IMO what is running is what matters. I say that because it seems feature detection has become the preferred way of making decisions when handling requests.

[elsigh]

It sounds like you only care about which version is "running"

[efouts]

Correct. ill go ahead and work on a PR that favors the trident token, when present, over the version token. In this case the existing fields work just fine.