-
Notifications
You must be signed in to change notification settings - Fork 159
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Consider adding #real_version to Base #42
Comments
Also, based on the changes in #30, I think that |
All sounds reasonable. I'd be happy to accept a pull request for Could you provide a test/example of where |
@gshutler The user agent from the spec added in #30 or one of the ones in the description of the PR would be good examples. If you were to call Now that I've had a day to think about this, however, I'm not sure it would be right for a It seems like you still don't want |
We are using
Errbit
for application error tracking and noticed that our error reports were erroneously saying "Internet Explorer 7" for some of our internal users who are actually using IE 11.Errbit uses this gem for user agent identification and it turns out that our corporate settings for IE are flagging our site as being in the Intranet zone, which automatically turns on "compatibility mode" (see here for the gory details). Our actual site is using
<meta http-equiv="x-ua-compatible" content="ie=edge">
to force the browser back out of compatibility mode, but by the time the server sees theUser-Agent
header it is too late for that to matter.I would like to make a fix to Errbit to have it call
#real_version
to get the actual version of IE being used in compatibility mode, but I would rather not have to add a call to#respond_to?(:real_version)
and bifurcate the code.Would it make sense to add this to
UserAgent::Browsers::Base
:If that were done, I could simply change the Errbit code to call
#real_version
instead of#version
and avoid this issue with compatibility mode.The text was updated successfully, but these errors were encountered: