Google Maps never supported IE on Windows Phone 8, and likely never will
thenextweb.com
thenextweb.com
"Internet Explorer in Windows Phone 8 and Windows 8 use the same rendering engine."
It appears that http://maps.google.com worked fine on Windows Phone until Google started blocking it. In fact it is still working on the Lumia 920 if I go to http://maps.google.co.uk as it looks like they forgot to redirect that one. Are there differences between how it works on Windows Phone and on webkit based mobile browsers? To say that "Since Internet Explorer is not a WebKit browser, Windows Phone devices are not able to access Google Maps for the mobile web" is simply not true. Internet Explorer on the desktop is not a WebKit browser and it works fine with Google maps.
It seems as though the reason that Windows Phone can't access Google Maps is that Google decided (for reasons they would need to explain) to start blocking Windows Phone users.
I don't ever remember Google Maps being blocked in Konqueror or IceCat, so I'm not sure why they are using this tactic on mobile. More importantly, a lot of good-citizen webdevs work at Google like Paul Irish, must be rather awkward for those types.
Stop making excuses for Google. This is ridiculous ffs.
Well played, Google
I wonder if, in 10 years, WebKit will be viewed as the next IE6 when the latest/greatest HTML rendering engine comes along?
What happened to standards compliance?
How come it's OK for WebKit to extend the spec with non-standard features but it was not OK for IE 6? Sure, some of the features have been standardized and included in other browsers, but the same thing happened with IE! You can thank IE for the XmlHttpRequest after all.
I can literally see no difference between IE6 adding non-standard features vs. WebKit doing it. You just have personal stake in WebKit succeeding and don't want to admit it's basically the same thing.
Historically, IE's new features have been developed for IE and Windows only. Then when competition had been sufficiently smothered, development on IE was simply halted.
Let's take Google Chrome's NaCl. It's eerily reminiscent of ActiveX is it not? Sure, Google open sourced it, but Mozilla and others have repeatedly criticized it. The web is not about sandboxing native code and creating some kind of Frankenstein platform within a platform where one can execute "native" code in a web browser. I mean, it's friggin' stupid. But it's OK because Google open sourced it and proposed it as a standard, right?
Or how bout Dart? Let me rush out and build my next application in Dart, because it's going to be standardized right? I mean, Google open sourced it so everyone could implement it!
There are some good things (WebM, SPDY) that have come out of Google, but those were incremental improvements and they allowed for graceful degradation or were alternatives to existing things.
> I'm all for innovation, but don't pretend that this is
> some altruistic plan by Google and Apple to move the web
> forward. It's about the same thing it was for Microsoft,
> keeping users tied to THEIR browser.
If Google cared about keeping users tied to Chrome, I suspect they would do more to discourage use of their greatest competitor's browser (Safari). > Let's take Google Chrome's NaCl. It's eerily
> reminiscent of ActiveX is it not? Sure, Google open
> sourced it, but Mozilla and others have repeatedly
> criticized it. The web is not about sandboxing native
> code and creating some kind of Frankenstein platform
> within a platform where one can execute "native" code
> in a web browser. I mean, it's friggin' stupid. But
> it's OK because Google open sourced it and proposed it
> as a standard, right?
The difference between ActiveX and NaCl is that ActiveX can only be used on IE and Windows, by design, but NaCl could be implemented by any browser vendor and run on any OS (so long as the user has an x86 processor).Also, NaCl is more of a prototype than a marketed product. Its obvious potential security issues prevent a more widespread adoption, and criticism from Mozilla (et al) are generally more on the technical aspects. The underlying goal of being able to safely execute native code is extremely important to the continued development of browsers as general-purpose operating systems (a goal I personally disagree with, but whatever). Someone needs to figure it out, and having an early first step proposed as an open spec is a good start.
> Or how bout Dart? Let me rush out and build my next
> application in Dart, because it's going to be
> standardized right? I mean, Google open sourced it so
> everyone could implement it!
I don't even know what you're arguing here; if NaCl is a prototype, then Dart is a tech demo, and one not even officially developed by Google. Chrome doesn't support it, and probably never will. You're essentially complaining that Google allows its employees to work on personal projects related to web browsers. > There are some good things (WebM, SPDY) that have come
> out of Google, but those were incremental improvements
> and they allowed for graceful degradation or were
> alternatives to existing things.
Everything is an incremental improvement, or an alternative to existing things.Edit: If you can't see any difference between the approach to standards taken by Microsoft with IE 6 and by the people involved with WebKit, I'd suggest reevaulating your own biases.
They probably figure if they let Google in on some things, then they open the door to supporting all of Google's apps like gmail, chrome, calendar, google docs, etc. Which goes against them wanting people to use outlook.com, their calendar, MS office and IE as their main browser.
I down-voted you because in this particular case this is not true, I'd say the opposite happens.
It's worth remembering that Android was developed in the first place to be an Open alternative to prevent Windows phone from taking off. Why would they go to all the trouble of developing Android only to prop up Microsoft.
Secondly, Google has market power in both the mobile device OS market and the online map market compared to MS, and is trying to leverage its position in the latter to hurt MS in the former. This seems like exactly your stated definition of anti-competitive behavior. How is this "intensifying" competition?
On the other hand, isn't the whole point of web standards to avoid situations like this?
I suspect we'll just get confirmation of something we really already know: standards are really important only when you're not the market leader.
How's that the same? Web is a agreed upon standard. An OS is not.
EDIT: To put a slightly different spin on it, it's easy to try to turn this into a moral issue rather than a business decision -- particularly with Google's foolishly-publicized "don't be evil" motto. But supporting multiple platforms requires additional resources, and companies have to make the business decision whether or not to provide them.
If you watch this video (or time travel back to about 4 hours ago and use a useragent string modifier) [0], you'll note that using a Lumia 920's user agent string [1] will redirect you to a desktop version of the site.
But now if you try it, the URL will redirect to the main search page.
[0] http://www.youtube.com/watch?v=_Z8vfzurnKw
[1] Mozilla/5.0 (compatible; MSIE 10.0; Windows Phone 8.0; Trident/6.0; IEMobile/10.0; ARM; Touch; NOKIA; Lumia 920)
The rules change, of course when we're close to a monopoly situation. But Google isn't at that point for either maps or mobile devices -- so at least legally, there's really no issue here.
I think that what people are really reacting to is that this is a decision which (at least superficially) is at odds with the way that Google markets themselves to us tech folks. And as such, it's a good reminder not to consume marketing messages without at least a few grains of salt.
I work at Microsoft (but not on any product related to these) and I'm quite certain that this was the case.
On Ubuntu at home, I used Chrome for most things. But I specifically installed Firefox to be able to use the "better" version of OWA. OWA would still work on Chrome, but it would automatically downgrade to the less-capable version.
Presumably, Chrome and Firefox were similar enough that the same code should have worked with both.
That being said, screw you Google, this is not OK. Maybe its business, but its not right. Time to start destroying my Google profile with Ghostery et al.
Err what? Does Chromium even have a API usable by third party devs?
Does it work with mobile gecko?
Regardless, I think Google Maps should try to draw something (no matter what browser the user has), with a big "unsupported browser" box. Redirecting to the home page is a user-hostile behavior.
I get that google needs to make money, I'm fine with it, but don't for one minute think they are the good guys anymore. They are as evil as any other public company. Sad but true.
Having put in all this effort to provide an open solution, they need to be somewhat competitive to make it succeed, otherwise it would likely languish the way the Linux desktop has.
From what I'm seeing, and to take just one example, IE 10 still doesn't support touch pan and zoom on mobile, which strikes me as a useful thing for a map application.
As you probably know, up until the release of IE9, supporting apps across the major browsers (Safari/Chrome, Firefox, IE) was a massive PITA. Not just obscure features, either; even IE8 had some crippling misunderstandings of the CSS 2.0 standard (floats). Today desktop cross-browser problems are consistent subpixel antialiasing and less-critical CSS features like border-radius support, so it's pretty easy for an app to [mostly] work in every modern browser without testing. Plus computers are fast enough that you don't [hardly] notice IE10's stupidly slow JS engine.
On mobile, that's not the case. Web-based Google Maps taxes my iPhone 4S Safari to the limit. It's so jerky it's hardly usable. V8 (Chrome's JS engine) is faster, so Android users might have more luck, but you're pushing your phone's hardware regardless. I haven't had the misfortune of owning a Windows Phone, but knowing Microsoft's previous disregard for standards, there may be some significantly broken features of IE10 mobile (though it supposedly supports HTML5 to the same extent as its big brother). At the very least, IE10 sees fairly significant lag with a few tabs on a recent desktop computer; I imagine JS performance on a phone is horribly unusable for an app like Google Maps. Optimizing JS for IE10 mobile could be a non-trivial task with diminishing returns—it might not even be possible to get it to run acceptably.
So there's a chance that capturing the 2% of the mobile market on Windows Phone isn't cost-effective for Google. It's probably political though—demos of IE Mobile have looked decent. [1]
Hopefully a real Google engineer can provide a more definitive answer though.
[1] http://thenextweb.com/microsoft/2011/02/18/watch-internet-ex...
http://crockford.com/javascript/performance.html
Besides how do you explain the uk site that was working already that then got blocked?
(Exactly. It's probably political as I mentioned before.)