IE11 on Windows 8.1 - Google Search loads in legacy mode
productforums.google.com
productforums.google.com
[1] http://msdn.microsoft.com/en-us/library/gg699485(v=vs.85).as...
(I work for Google, on unrelated things.)
It's lazy/incompetent practice, which shouldn't really excusable for such a supposed massive advocate of web standards. MS are no shining example, but it's pot calling kettle black.
Definitely a Google bug - a long standing one
Some things aren't feature detectable, like actual weird bugs in behavior that need browser specific workarounds.
In this case it looks like MS has the domain listed for their fallback mode, which doesn't just change the UA but actually changes the browser behavior (IE9 in IE8 mode has no canvas support and will fail the feature detection for canvas appropriately).
It sounds like Microsoft screwed up their list, but IE saying 'MSIE' is not a bug by any stretch of the imaginations. The bad code here is all on Google's end.
Oversights can happen of course, but trying to blame Microsoft when the real cause was Google's bad browser sniffing is just weak.
Click on "Known compatiblity issues". Notice the "Request tech details on your site" link.
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.
Not saying this is malicious. Maybe just Google is doing something silly. Maybe Microsoft have slipped up on their compatibility-list-thingie (which is a horrible invention IMO).
Sometimes adding too many special cases in your code instead of having one "good enough" version for everyone will cause you a million problems you never saw coming. I've had more bugs come from special casing than any general, "run everywhere" code I've written.
I can easily see how both ends could be responsible for this problem, even at the same time.
"Probably not, but let's mess with 'em anyway."
"Hey, if we make Google uglier, maybe people will use Chrome!"
"Probably, they are used to IE not working"
Not sure who had the slip-up, but evil works both ways :P
That's the solution posted in that thread. It's an IE problem.
ETA: In standards mode, IE sends "Mozilla/5.0 (Windows NT 6.3; WOW64; Trident/7.0; rv:11.0) like Gecko".
I'm going to choose to apply Hanlon's Razor in this situation.
-How often do people who have to do something to detect chrome/firefox version? Unless you are doing something with bleeding-edge experimental APIs probably, never.
-How often do people have to do something for a specific version of IE? All the time.
Chrome & Firefox have been mostly compatible for the past 20 major versions. IE has yet to make two consecutive versions compatible with each other.
Also worth noting: Firefox and Chrome support more versions of Windows than Microsoft's past 3 Browser releases have.
Again I don't this is necessarily a distinct case of anybody trying to be evil. This is just a symptom of a bigger problem.
By not working, I mean, not working at all. If you are lucky it has the whole text you typed and the search button might wake up after 3 or 4 clicks. It is the only site I had problem with using IE11.
IE11 -> Tools -> Compatibility View Settings. Remove check on "Use Microsoft Compatibility lists".
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?
<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'.
This problem just started in the last 24 hours - Google rendered fine and was my default search engine for over a month running the 8.1 RTM, and for a few months before that running the 8.1 Preview.
This isn't MSFT's fuck up unless Google is doing feature detection and IE11 is presenting itself as not supporting some trivial HTML5 feature.
Edit: I stand corrected - it looks like something MSFT pushed out as a compatibility list update around the general availability of 8.1 is causing this.
On the other hand, it's very strange that it suddenly occurred in the past day, when I've been running 8.1 release for over a month.
Anyway i also have a lumia but I set google as search engine in ie mobile
Enabling/disabling Compatibility View has no effect - it looks just fine to me either way.
Never assume malice when ignorance will do.
Someone broke something, probably not intentionally. Microsoft has a shady history here, Google has a shady history here (esp. with hostile treatment of Microsoft user agents with YouTube and Maps!), so in the absence of further evidence let's not point fingers.