Google Maps never supported IE on Windows Phone 8, and likely never will(thenextweb.com)
thenextweb.com
Google Maps never supported IE on Windows Phone 8, and likely never will
http://thenextweb.com/insider/2013/01/05/the-windows-phone-8-google-maps-kerfuffle-is-contrived-google-maps-never-supported-ie-on-wp8/
12 コメント
Google is taking the bizarre position that only iOS and Android exist on mobile (and only the official browsers of those platforms).
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.
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.
I can't help but wonder if Google are trying to ensure they stay as the major non-Apple player. For all the popularity of Android, it is a far less interesting offering for a long-term iPhone user than Windows Phone.
I wonder the same thing. It seems like Google is trying to make Windows attempt to enter the market as painful, and played out, as possible. (I'm talking about Windows Phone 8, obviously they've been players for a while).
And this just days after FTC cleared them if any misbehavior. Bravo!
The FTC cleared them of antitrust. This is just normal business competition.
But the EU hasn't. :-)
Well if EU can be influenced by lobbying as FTC can be then EU will clear them as well
And yet... you can use it to visit maps.google.co.uk [0].
Stop making excuses for Google. This is ridiculous ffs.
[0] http://www.youtube.com/watch?v=_Z8vfzurnKw
Stop making excuses for Google. This is ridiculous ffs.
[0] http://www.youtube.com/watch?v=_Z8vfzurnKw
Note that the video shows the user able to access the desktop version, but the article is about accessing the mobile version. Here's what the mobile UI looks like: http://i.imgur.com/oCveo.png
well neither works on windows phone.
[deleted]
I cannot test it myself. But there are many people in the comments saying it doesn't work on co.uk either. Maybe it was only working when the uk version was outdated.
I tried it with a user agent string modifier (went to maps.google.com.au) a few hours ago, and it worked. I tried it again, redirects me to the main search site.
Well played, Google
Well played, Google
Bizarre.
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?
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?
Honestly I think the title is just PR BS from Google. You can use WP8 browser to access maps.google.co.uk and it works perfectly fine [0]
[0] http://www.youtube.com/watch?v=_Z8vfzurnKw
[0] http://www.youtube.com/watch?v=_Z8vfzurnKw
That's a video of the desktop UI, not the mobile UI. Users are complaining that they can't access the mobile UI.
Actually, I'm on wp8 and I can access neither. Maps.google.com just redirects me to the mobile version of google.com
WebKit is constantly moving forward, and is not stagnant like IE6 was. Many of its initially-proprietary web features have been standardized and adopted by other browser engines. The primary challenge is convincing web authors to support the standardized versions of the formerly-proprietary features alongside the browser-specific versions.
Personal bias much? I see you work on Safari at Apple.
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.
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.
When Firefox, Chrome, or Safari add new features, it's with an eye toward getting those features into the appropriate standard. The goal is to have as few proprietary features as possible.
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.
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.
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.
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.
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.
[deleted]
> 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.
> 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?
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!
> 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.
The major difference is that Microsoft wasn't actively working with the various web standards groups to standardize its various proprietary features. The majority of the non-standard functionality that's added to WebKit and Gecko is done with the intent of moving it on to the standards track if it is beneficial to the web platform.
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.
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.
The reason its not supported is not because of technological limitations. It's just anti competitive practices from Google.
There is nothing 'Anti-Competitive' about not providing your free service to customers of your competitor. If people want Google services they can choose Android.
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.
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.
Of course it's anti-competitive! They took something that was working on a competitor's phone platform and intentionally caused it to stop working. It's probably not illegal, but if it's designed to harm a competitor it is by definition anti-competitive.
Not adding value to your competitor's products for free is simply competitive and part of normal business. "Anti-competitive" is a different thing and means using market power to suppress competition, whereas this move is about intensifying it.
First of all, forget "not adding value to your competitor's product" - this is about removing value that was already there.
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?
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?
There are multiple players in the map market, Microsoft themselves being one of them. Google are competing against Microsoft by asking customers to choose between their integrated mobile offerings rather than supporting Microsoft by giving them a second maps option for free.
Can't you just install a different browser on WP8? Or is Microsoft locking down their platform to only the IE engine?
I'd say its just the opposite. It's anti-competitive practices from MS. They're trying to build their own walled in hardware/software garden. It would make more sense to me if MS was blocking Google stuff, not the other way around.
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.
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.
> It's anti-competitive practices from MS.
I down-voted you because in this particular case this is not true, I'd say the opposite happens.
I down-voted you because in this particular case this is not true, I'd say the opposite happens.
On the one hand, this isn't really any different than Microsoft not supporting Office on Chromium.
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.
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.
> On the one hand, this isn't really any different than Microsoft not supporting Office on Chromium.
How's that the same? Web is a agreed upon standard. An OS is not.
How's that the same? Web is a agreed upon standard. An OS is not.
It's the same in the sense that a company with a product isn't necessarily obligated to support all potential platforms for that product. But maybe a better comparison would be to point out that web access for Exchange was not officially supported on Chrome for many years.
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.
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.
No, it's not the same. It's one thing to say a product isn't obligated to support all potential platforms, it's another to actively disallow other platforms.
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)
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)
Companies do things that hurt their competitors all of the time. Often, consumers are the beneficiaries (at least in the short term) -- as is the case when a new entrant into a market is able to provide a better or cheaper service, and supplants an older or less efficient competitor. There's nothing inherently wrong with this. Other times (like now, or when Google announced it was ending support for ActiveSync), the decision is a little more ambiguous. But in both cases, there's a potential cost for Google that's being avoided -- and that aligns nicely with competitive considerations. I don't think we want to live in a society where anyone can be legally compelled to provide a service at a loss to a small number of users.
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.
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 don't see it as at odds with how they market themselves. They position themselves as providing an Open, non-proprietary option as an alternative to monolithic and traditional closed solutions from Apple and Microsoft, and they are delivering on that in the form of Android.
Why should Google provide their service for free to their competitor's customers?
They have no obligation to do so. But then why not be honest about refusing service to users of a competing platform, rather than claiming that it's about the technical capabilities of the browser? This is something that was working on WP devices until today and has been intentionally disabled.
Office Web Apps work fine in Chrome/Chromium.
Sure, they do now; it's a pretty sensible business decision given Chrome's market share. But there was some period of time after it came out -- I can't recall how long -- when Chrome was officially not supported by OWA (Outlook Web Access).
I work at Microsoft (but not on any product related to these) and I'm quite certain that this was the case.
I work at Microsoft (but not on any product related to these) and I'm quite certain that this was the case.
The reason chrome was not supported earlier is probably because OWA possibly used some arcane and non-standard IE features that were lacking in chrome. Also AFAIK it never blocked the OWA outright (by redirecting to some other url instead)
My specific recollection is this:
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.
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.
Additionally, for years and years (until maybe two years ago) they did the same in Firefox, where you always got the less capable version that had no means to delete multiple emails at one. Man, that was annoying.
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.
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.
OWA specifically redirects Chrome for Linux to an older, static-html version. You have to spoof Firefox for Linux or spoof Chrome for Windows in order to get the rich client UI.
>On the one hand, this isn't really any different than Microsoft not supporting Office on Chromium
Err what? Does Chromium even have a API usable by third party devs?
Err what? Does Chromium even have a API usable by third party devs?
The mobile web version of Google Maps is optimized for WebKit browsers such as Chrome and Safari.
Does it work with mobile gecko?
Does it work with mobile gecko?
Sort of; using Firefox 17, the mobile UI loads, but is very jerky and zoom doesn't seem to work.
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.
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.
Don't be evil, Google.
Please remember it.
Google have provided a free, open source alternative to Windows Phone. There is nothing 'evil' about them not supporting other platforms.
Of course it's evil. Redirecting a user is hostile in nature and was surely done to piss off microsoft. What wouldn't be evil is putting a banner stating that the browser is not supported.
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.
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.
They're the only ones providing an Open Source mobile OS. Without them, we'd have only proprietary solutions controlled by single corporations.
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.
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.
As a Windows Phone user in China, the feeling is very familiar. Bravo, Google, you've certainly learned a few tricks from the bloody Communists.
I imagine there's a good market for a meta-mapping app that lets the user easily switch their views from various mapping services and providers. It would essentially be a webview that kept each map open on a different tab but with a smarter custom ui and animations for switching.
IE across ALL mobile devices currently represents less than 2% market share according to NetMarketShare. In other words, less than the Blackberry browser. Would you optimize YOUR product for that?
Who said anything about optimizing here? Supporting and optimizing are two separate things.
OK. Would you do the work to make your product SUPPORT 2% of the market?
It works fine today. No work is needed by Google. They did more work to redirect the traffic.
Maybe Google is tired of the ongoing maintenance hassle and doesn't want to pay to write all the special-case code that will be necessary to support IE in future versions of their maps product.
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.
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.
What work? They can just let Windows Phone users access the site and fend for themselves. I would say writing the code for the redirect is more work.
Except that the customers would then blame Google when something didn't work. No one likes to get blamed for the shortcomings of others.
[deleted]
Many Google engineers here. Anybody care to explain what are the technical reasons why this would be not supported?
Not a Google engineer, but I can offer a partial explanation.
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...
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...
AFAIK, IE10 on mobile has the same JS engine as the desktop one. What data you have to say that it is slow? This benchmark says its the fastest:
http://crockford.com/javascript/performance.html
Besides how do you explain the uk site that was working already that then got blocked?
http://crockford.com/javascript/performance.html
Besides how do you explain the uk site that was working already that then got blocked?
All anecdotal. Maybe it's Trident (the rendering engine) then, but it really hangs for me after a few tabs.
(Exactly. It's probably political as I mentioned before.)
(Exactly. It's probably political as I mentioned before.)
They won't, they care about having a job to go back to come Monday.
"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.