IE11 -> Tools -> Compatibility View Settings. Remove check on "Use Microsoft Compatibility lists".
IE11 -> Tools -> Compatibility View Settings. Remove check on "Use Microsoft Compatibility lists".
<domain docMode="EmulateIE10" versionVector="10" uaString="10" featureSwitch="overrideXUACompatible:false">google.com</domain>
It seems to read as: render and present as IE10, and if there is a `<meta` tag specifying x-ua-compatibility, don't ignore it.There's another section that overrides the backwards/forwards cache setting for google.com:
<BFCache>
...
<domain exclude="true">google.com</domain>
But I've no clue how that would affect rendering so much.I've disabled both settings (commented out) and will report back if commenting them out fixes Google.
Google is detecting the user agent string and attempting to use features that should be supported. e.g. google's code is trying to use some IE11 feature that IE10 didn't support. The compat settings are making this fail which seems to cause google's code to drop to it's lowest compatibility mode (IE 6?) as some sort of 'compatibility panic'.
I'd expect google.com to be fully standards compliant, but for some reason I believe IE was forcing itself back to IE8 mode for it. Never understood why. Even in IE8 mode though, this should have worked fine- so could be something worse (identify as IE8, execute as IE11?).
Furthermore, by using compat mode, the only way for google.com to use newer features in IE is to ask Microsoft to take it off the compat list then push an update to all IE browsers.
In general, this compat list should die and sites should be targeting standards-compliant behavior. If they identify as standards compliant and are not, bugs should happen.
Unfortunately, we see otherwise during our compat testing here at Microsoft on many occasions.
If it works fine without being on compatibility mode, don't add it to your compatibility mode list.
> I'll tell you more guys. I've updated to windows 8.1 on my tablet a month ago through MSND subscription and Google search worked just fine. Looks like this problem appeared after public availability of Windows 8.1. So I believe it's something that Google or Microsoft should figure out.
How could they have tested as they were not on the list until, what appears to be, the public release?
To score some cheap points against a competitor you made your own product inferior. Good Luck with that attitude.
We're very proactive in our compat outreach and we've had numerous conversations with sites like Google. Sites like Google are VERY aware of the CV list & the modes they're rendering in; it's not a surprise to them.
Don't assume we're doing something nefarious when it's not the case. We have nothing to gain (and a lot to lose) by breaking one of the top web properties, even if they're a competitor.
Here's a more plausible scenario. Google may have made a change to their SERPs which didn't work great in the docmode that IE11 is rendering it in. Nothing intentional, nothing nefarious on either company's part.
I think that's a more reasonable explanation than the concerns you're expressing.
[1] If it had worked fine, it would never have been added in the first place. [2] Sites like Google are VERY aware of the CV list & the modes they're rendering in; it's not a surprise to them.
Those 2 together are suggesting Google knows problem all along and you have been working with them but they didn't fix the issue.
Mozilla/5.0 (Windows NT 6.3; Trident/7.0; rv:11.0) like Gecko
If not, can you please elaborate on this:> If you currently use the x-ua-compatible header to target a legacy document mode, it's possible your site won't reflect the best experience available with IE11. For more info, see modern.ie. ?
If a site is on the list and they declare "edge", will they see the real ua string? What can someone on the list do to get the real ua string?