101–110 of 127 posts
Earlier quoted context omitted.
Well, WebGL doesn't work in Chrome on Android either.
True, though that may change soon. And other features like SPDY are already working on Android but presumably not in Chrome for iOS.
Earlier quoted context omitted.
What's pretty nauseating about it is that it's exactly the kind of anti-competitive crap that Microsoft pulled in the first browser war, only more so.
Why do people keep bringing this up? The situations are completely different. Microsoft bundled IE with Windows at a time where the internet was still painfully slow and it was difficult to download a different browser. They also allegedly put IE-specific APIs into Windows, giving it an unfair advantage. However, neither of these would have been enough to convict, if Microsoft hadn't also had a monopoly over the PC.…
And also like many others have said before, that's not a difference. You could choose not to buy Microsoft products in the '90s. I did it. The place I worked did it. Most people and places simply didn't make that choice because Microsoft seemed like a safer purchase.
Also, Apple has pretty much the same position in the tablet market that Microsoft did in the PC market. I can't remember the last time I saw someone holding a non-Apple tablet who wasn't trying to sell me one.
Earlier quoted context omitted.
Its not JavaScriptCore, its webkit (UIWebView which is non-Nitro). Tab syncing is one heck of a benefit, I can't wait to switch. Now I'm definitely going to stick with Chrome on my desktop, even though I'd been considering going back to Firefox. Quite disappointing on Apple's part that its only in iOS 6 that Notes and Calendar will be synced with OS X, still not Safari tabs.
Is JavaScriptCore not the WebKit JavaScript engine? My point was that one of Chrome's main allures is V8, and if it's using stock WebKit (and therefore JavaScriptCore) there doesn't seem to be much point in using Chrome at all.
Earlier quoted context omitted.
Its not JavaScriptCore, its webkit (UIWebView which is non-Nitro). Tab syncing is one heck of a benefit, I can't wait to switch. Now I'm definitely going to stick with Chrome on my desktop, even though I'd been considering going back to Firefox. Quite disappointing on Apple's part that its only in iOS 6 that Notes and Calendar will be synced with OS X, still not Safari tabs.
Doesn't Safari on iOS 6 include tab sync? http://techcrunch.com/2012/06/11/safari-on-ios-6-to-feature-...
Does Chrome on iOS support WebGL?
Earlier quoted context omitted.
I don't understand why they can't sandbox the UIWebView. That's how mobile Safari (presumably) is secured, as is Chrome. It has to render/execute untrusted content in any case.
Performance, probably. To sandbox it I imagine it would have to run in a separate process, and then you'd have to pass messages back and forth, which might be slow. But who knows. It may be one of these things they were planning to do later, and then someone pointed out it would possibly be detrimental to what they want the iOS ecosystem to be, so they scrapped plans.
I wonder if its possible to sandbox a thread as opposed to a separate process. I doubt that Apple consciously neglects HTML5 app SDK functions. iOS has been the best platform for HTML5 for a couple of years already, supporting features (CSS 3d for one) that Android didn't.
Earlier quoted context omitted.
What a bunch of walled-garden bullshit. It's not even clear that having a full featured Chrome would hurt Apple in anyway
>It's not even clear that having a full featured Chrome would hurt Apple in anyway Perhaps this is how Apple sees it: The browser might create a SDK that makes web apps work more like native apps thus resulting in reducing Apple's control over apps. Also, look at things like NaCl and how plugins like Flash might be enabled by browsers with rendering engines.
A cynical mind might think they did that specifically to keep HTML5 from getting any closer to replacing the app store.
The icon is similar to Gmail on iOS - "wide" black margins. Any idea why? Everything else seems to be working just fine, not slow or anything. The omnibox is really nice.
Earlier quoted context omitted.
I keep reading, there is no tablet market except for ipad. Why is that not considered monopoly?
Let me preface this with IANAL, just a very interested person. It may very well be, but having a monopoly alone isn't not a crime. A crime in this case would be abusive practices of the monopoly. What makes United States v. Microsoft different is a number of factors but the main factor was its restrictive licensing agreements with other OEMs. You could buy a computer from a variety of makers, but no matter what, this…
Like not allowing third-party browsers to compete with your own on anything remotely resembling a level playing field? That's what we were talking about here, remember? Apple won't allow alternative browser engines at all, and if you decide to build a browser using the engine Apple provides for third-party devs, it's worse than the one Apple uses in its own browser.
> Apple does not have a monopoly over the dominant operating system for all tablets, only its own. Yes right now it is the dominant product in the space, but alternatives readily exist with the same availability as the iPad.
Macs were not particularly less available than PCs in the '90s. I didn't know anyone who really wanted to buy a Mac, but just couldn't find one. They were just radically less popular and generally considered to be a bad choice (I liked them even then, but I didn't have a lot of company with that opinion). Much like non-iPad tablets.
Earlier quoted context omitted.
Performance, probably. To sandbox it I imagine it would have to run in a separate process, and then you'd have to pass messages back and forth, which might be slow. But who knows. It may be one of these things they were planning to do later, and then someone pointed out it would possibly be detrimental to what they want the iOS ecosystem to be, so they scrapped plans.
Message passing between a UIWebView is already one of the big complaints, requiring slow and klunky workarounds. To receive a message you detect URL anchor (#foo) changes in objective C. Sending is a bit better (inject a js string). I wonder if its possible to sandbox a thread as opposed to a separate process. I doubt that Apple consciously neglects HTML5 app SDK functions. iOS has been the best platform for HTML5 fo…