Is Apple Blocking Google’s Chrome Browser on Me.com?

mechrome Last month I made the change from an Exchange hosted service to Apple’s MobileMe / Me.com . So far, I’ve been pretty impressed with the services, the cost, and the reliability of the sync process. Apple has clearly made some headway since the disastrous launch last year.

However, all is not good in Google Chrome and Me.com land.

After getting Chrome installed on my loaner Vista-based Lenovo X200 Tablet PC and Windows XP-based HP Mini 1000, I hit up my account at Me.com, and what do I get — a blank screen.  No warning of a better experience with Firefox or Safari, no warning that Chrome is no longer supported, no message of pending problems. Nada. Nothing. Just a blank screen.

After a bit of research, it appears that Apple made some sort of change between December 15th and the 19th. Users on MacRumors forums, Apple forums, and Chrome forums are reporting the same problem; and, it doesn’t appear that a resolution is near at hand. What is odd about this particular problem is that both Apple’s Safari and Google’s Chrome are based on the same rendering engine: Webkit. In addition, many users have reported me.com running blazingly fast using Chrome. A search in their help system revealed the following helpful results: Found 0 matches searching for chrome. Displaying matches 0 to 0.

Until Apple gets this problem fixed, and because Internet Explorer 7 isn’t fully supported, it appears that users will be stuck with Firefox or Safari to get access to their MobileMe data via Me.com.  At the very least, Apple needs to issue a communication to their MobileMe customers regarding Chrome support and why it has suddenly stopped working.

8 Comments

  1. Interoperability

    01/02/2009 at 11:10 pm

    So much for Mobile Me, unmitigated disaster after disaster since launch. Just to satisfy my curiosity, I visited http://www.me.com with Chromium 1.0.156.0 nightly builds and can confirm it doesn’t work, just gives a blank page.

    Luckily Gmail works just fine in Chromium 1.0.156.0 nightly builds and Minefield 3.2a1pre nightly builds.

    Reply

  2. DP

    01/03/2009 at 1:07 am

    While the browser issue is indeed troubling, would you mind commenting on what specifically it is that you like about MobileMe, perhaps even doing a full review of its present incarnation at some point? Most things I read about it say that it’s still pretty rough around the edges — not just the sort of thing you mention here, but extremely slow loading times, stalling, and the like. If the service has, in fact, worked out most of its major kinks, I’d love to know! For those of us who never cottoned to the idea of hosted Exchange, this has, conceptually, at least, always SOUNDED like a great alternative.

    Reply

  3. Andrew Ferguson

    01/03/2009 at 2:35 am

    This issue appears to be some faulty JS, specially Chrome is reporting

    “Uncaught TypeError: Cannot read property ‘1’ of null http://www.me.com/my/shared_100/en/bootstrap?271888787. (line 157)”

    The exact piece of code in question deals with determining the version of a Safari browser. I suspect that since Chrome masquerades as Safari to some extent, the JS is barfing when it tries to figure the version number.

    Reply

  4. Rob Bushway

    01/03/2009 at 9:30 am

    @dp I will get to that after CES

    Reply

  5. Kristian Bjornstad

    01/03/2009 at 1:36 pm

    I have the same blank screen, but this time in OmniWeb on the Mac. Just nothing, no matter how long I wait for it.

    Reply

  6. Michael Maggard

    01/03/2009 at 2:46 pm

    Same for Android-based devices, which also use WebKit. The T-Mobile G! with Google is unable to access MobileMe sites & services, much to my dismay.

    My suspicion is MobileMe simply detects a WebKit browser then automatically supplies Apple-specific code to it. Presumably some of of this material only makes sense to Apple’s implementation of WebKit, thus the incompatibility.

    If these guesses are true than it should be relatively straightforward for MobileMe to adopt more conventional browser/OS sniffing to further refine it’s supplied pages and differentiate between generic-WebKit (Chrome, Android, Nokia, etc.) and Safari-WebKit.

    Reply

  7. Gérard

    01/13/2009 at 8:51 am

    I believe there is a bug in the browser detection script and the page just stops loading when the script sees the Chrome user agent string.
    If you fake it and make Chrome’s user agent info look like Safari, the page loads fine. Just start chrome with the following parameters:

    chrome.exe –user-agent=”Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/525.19 (KHTML, like Gecko) Version/3.1 Safari/525.19″

    I have sent that feedback to Apple a week ago but I doubt that anything sent via the feedback page ever reaches someone at Apple.

    Reply

  8. Gérard

    01/13/2009 at 8:59 am

    looks like the blog is eating consequent space characters :)
    correct command is:

    chrome.exe[space][minus][minus]user[minus]agent…

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *