Perhaps one of BrowserHawk’s most powerful features is its intelligent Automatic Version Detection (AVD). This feature enables BrowserHawk to detect new minor version releases of browsers (such as Safari 7.0 to 7.01), or even major versions, such as Chrome 30 to Chrome 31, automatically without the need for you to update your browser definition files. For example, with basic browser sniffing scripts a version change from 7.0 to 7.01 results in a browser being unrecognized – even though that browser’s features were no different that the 7.0 version. AVD eliminates this problem entirely.
And equally important, AVD dramatically reduces the number of definitions necessary to cover all these versions. As another example, what would take several hundred entries just to cover Chrome alone can be handled by just a few entries in our BDF.
Important information on enabling and using AVD:
To enable AVD, set the Majorver property = "-1". If you do not see this property listed in the Properties Window Pane, be sure you have set BrowserHawk to display Version properties. This tells BrowserHawk that it should use AVD to automatically set all version related properties for that browser when a matching user agent is presented.
This allows you to use AVD while selectively setting version properties on your own for special browser definitions. This is necessary, for example, in cases where a user agent string does not contain a valid version number but you would like to assign on anyway (otherwise all version properties will be set to zero).
If BrowserHawk matches a user agent for a browser with its Majorver property set by you to be -1 (default), it will use AVD to override Majorver and all other version related properties to the values detected within the user agent string.
Finding the right version number within the user agent string:
Many browsers report several different version numbers within a user agent string. In these cases it is necessary to tell BrowserHawk which version number in the string represents the version number for the browser.
For example, consider the following user agent string for Internet Explorer 11:
Mozilla/5.0 (Windows NT 6.3; Trident/7.0; rv:11.0) like Geck0
From BrowserHawk's perspective, which one of those version numbers represents the browser's version number – "5.0", "6.3", "7.0", or "11.0"? The answer is that BrowserHawk uses the Versionpos, Versionposstr, and Versionposx properties to determine this.
Versionpos tells BrowserHawk which position number from the left a version number is. For example, in the above user agent, the real version number we are after is located in the 4th position, so we would set Versionpos to 4.
That is sufficient for some cases, but not all. Consider now what happens when a variation of this user agent string comes in with an extra version number in it (shown below as "2.0") like so:
Mozilla/5.0 (Windows NT 6.3; Trident/7.0; custbar 2.0; rv:11.0) like Geck0
Now the version number would be detected as 2.0, which would be incorrect. This brings us to the power of the new Versionposstr and Versionposx properties.
Enhanced Automatic Version Detection
Prior to BrowserHawk 8.0 and its newly introduced Versionposstr and Versionposx properties, the problem with Versionpos being a fixed value was handled by creating multiple copies of the same browsers in the BDF file, and varying their Versionpos value based on matching templates that accounted for different possible positions of the version information.
This process was repeated, resulting in dozens of entries to try and accommodate just one major browser type and version, such as Opera 9. This resulted in some bloating of the browser definitions, and even with all this effort, the version detection was still incorrect in some cases (as it is not possible to predict in advance all the possible combinations). With the growing popularity of Firefox and other browsers, a more efficient and accurate approach was needed.
Starting with BrowserHawk 8.0 we introduced the new Versionposstr and Versionposx properties. These properties allow us to achieve great accuracy in version detection, while only requiring one browser definition instead of dozens.
Versionposstr is a string that serves as a marker to BrowserHawk. It indicates that the version number comes Versionposx positions after the Versionposstr string. For example, with Versionposx set to 1 and Versionposstr set to "Chrome", BrowserHawk knows that for:
Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.63 Safari/537.36
the version is 31.0.1650.63, regardless of what comes before or after that version number, and regardless of how many version numbers appear in the user agent. Therefore one definition now will result in the version being detected accurately.
Generally Versionposx will be set at 1. However this number can be positive or negative to tell BrowserHawk to move forward or backward (respectively) x number of version positions to identify the correct version. Likewise Versionposx could be used to identify the last version number in the string by being set to -1 with Versionposstr set to "", or the 2nd to last version with Versionposx set to -2.
In summary, the Enhanced Automatic Version Detection (EAVD) introduced in BrowserHawk 8.0 ensures the most accurate version detection possible, while keeping the browser definitions tight and efficient (no bloat), while also providing maximum flexibility in the future as user agent strings continue to become more complex to parse.
Tip: The information is for reference only. It is never necessary for you to change or worry about the Versionpos, Versionposstr, or Versionposx properties unless you are creating your own custom browser definitions, as cyScape handles this for you as part of your software maintenance through the BDF updates.
See Also: