Chrome Fits Gently The Problems In Leo Compatibility

Chrome users spent on Lion will have noticed that some of the new OS are poorly or not supported by the browser. The scroll bar does not take into account the settings of the OS for its display, full screen mode is not suitable (but also gestures are not supported). Chrome has a full screen, but it does not behave as standard. Several adaptations of the software are in progress, as reported by Sundar Pichai of Google to TechCrunch.

Chrome currently displays many of the new button switches to full screen. But in this state, the browser will not display the toolbar. It does not propose the button to leave the full screen; it must be done by the menu or keyboard shortcut. Then, in Mission Control Chrome full screen is displayed among the other applications in the upper area of the screen.

Regarding the lack of toolbar, one of the developers of Chrome reminded that this presentation is desired. Google wants to give up space on page and the bar is displayed at the approach of the mouse. We are then in what amounts to a format. And the idea of adding a preference to software sorrow too.

In contrast, Safari offers an in-between, this is to maximize its display, but without depriving the user of the button bar and its tabs. Initially, the developer engaged in the discussion Chrome has refused to return to this established principle. Through the exchanges, the position has evolved. The adoption of the full screen, it requires a little work because the button bar of Chrome does not use the standard resources of Mac OS X.

Google has initially removed the full screen button as it appeared in Lion does not lead to a standard behavior. What can the user aback? The withdrawal is effective now since the latest beta. The scroll bar also has it normally. Then the developers will seek to stick as close to full screen mode as Lion, and test the principle of a button bar that can be displayed in this presentation.

In parallel, a participant in the debate has compiled a version of Chromium start offering more standard behavior.

Another planned development, this time on the support of gestures to move between page views. In the final version of Leo, this movement is, by default, with two fingers instead of three (it's option adjustable in the preferences of Mac OS X). Chrome, however, does not understand the gesture with two fingers. We must therefore modify the basic settings of the OS if you use a Magic Trackpad. There is also a developer - who has in the meantime with Trackpad Magic - said to have addressed the problem.

Google improves search in Chrome

Google has introduced three new features to its search engine for computers. Two are reserved for users of Chrome, Google's browser; even if we can assume that the compatibility will be extended to other browsers in a second time.

Issue of mobile voice search is now also accessible from the desktop version of Google. Operation is very simple: when it is available, a microphone appears in the search field. Simply click and dictate the request to search. This function is reserved for Chrome, it's actually an API created by HTML 5 and Google is clearly not used elsewhere in Chrome, since version 11.

Also new this time open to all browsers, the search images. This feature was also initially being available on mobile devices with Google Goggle: the search engine will scan the image and search based on what he finds. Several possible uses such as finding the name of a plant or building are simply a different way of search.

Google is proposed three ways to launch a search with an image. The simplest is undoubtedly the drag / drop an image into the search field of Google, but probably not only work on all browsers. In all cases, you can also click on the icon of camera added to the search field to select an image on your hard drive, or even just copy / paste an image. Google has even developed an extension for Chrome and Firefox.

The third novelty of the day does once again that Chrome. Google still wants to speed up the search for the users of its browser by loading in advance the first search result. The company is betting that the first result is the one most likely to correspond to your research and place it in the browser cache. When you click on the link, it loads immediately.

Effective if we are to believe the video, but it will wait a bit to use this feature. Google says you can test it with the development branch of Chrome, but that the domestic beta is expected soon to experience it. It should be a priori accessible to as many people in Chrome 13.

WebM-H264-Flash

Then move on to content providers: the first one, YouTube, supports both the H.264 WebM. Beyond that, we must also look to find videos in WebM. And for good reason: this waltz codec has a cost, not just storage, but also encoding.

Content providers are primarily looking for the highest common denominator between all browsers and all platforms. For now, the duo Flash and H.264 that wins, because the plug-in Adobe can play H.264 video in browsers that do not have this feature. Similarly, IOS, Flash private, can play videos in H.264 format, like most mobile platforms.

Take the case of Daily motion, which hosts some 16 million videos, the 3G format (240p), SD (380p), HQ (480p) and HD (720p). To fully support the WebM, should convert each video to each of these resolutions, to ultimately do not get absolutely any benefit from the perspective of the host: support for WebM would not increase the scope of the site. Besides Daily motion receives many videos already encoded in H.264 with regard to the quantity of material to support this format natively, and encoders WebM are two to three times slower than their counterparts in H.264. Recognizing further that the MPEG-LA has decided to permanently abandon his royalties on the free dissemination of content in H.264, WebM does not even compensating on that plane.

Adobe has already announced plans to add support of WebM in Flash, and Google also speaks of a plug-in to read the WebM (probably as a codec for QuickTime and Windows Media rather than a plug-ins for each browser, read WebM: freedom, politics and ... installing plug-ins). It nonetheless remains that IOS cannot read the WebM. Site publishers who wish to remain accessible on the Apple devices will be well advised to keep H.264, which will remain readable in Firefox, Chrome and Opera through Flash.

And that's where Google's announcement demonstrates its adverse effects, far from encouraging the abandonment of Flash, it only strengthens his position. Some observers have also not failed to raise an inconsistency in the attitude of Google, if it abandons the H.264 for philosophical questions relating to proprietary code, what does the code of Flash within the one Chrome? And what about other Google products that retain their support H.264? Olivier Poitrey, technical director of Daily motion, does not mince words: "Google wants us to believe that his only interest is to advance open source, but keeping the support of this proprietary format in YouTube, Google Android and TV it demonstrates the hypocrisy of his actions. "

Also remains the thorny question of hardware acceleration, which is crucial for mobile devices, and so far the exclusive domain of H.264. Certainly, the support of WebM in hardware has been promised, but what about the current generations of hardware, and various contractual commitments with its partners YouTube?

Safari, a victim of his age?

But if there's one application that one might be tempted to apply this perspective, it's Safari. A French window all the more sensitive it is open to a world where hostility is not lacking. And then, Apple has fallen behind Google and its sensitive Chrome: it is fully designed to isolate processes from each other and HTML rendering extensions, is the concept of sandboxing, confinement in bins sand, literally.
Safari for Mac could give the impression to use the sandboxing for plug-ins like flash, but isolation is not complete - it is just there to prevent the component to crash the browser.

Mac OS X Lion could change somewhat the situation: a new process is associated with Safari, and it could be exclusively dedicated to rendering HTML, Safari Web Content (read: Safari 5.1: separate processes and WebGL). But it remains far from that Chrome isolates each tab in a dedicated process. And for Miller, Apple has "failed - or did not seek" to make regularly available for Safari updates made to its rendering engine, WebKit. As to better illustrate this assertion, Chrome has already enjoyed a patch for the vulnerability exploited in the last Pwn2Own to make him fall.