[webkit-dev] WebKit and Android
Hello WebKit! We would like to give an update about WebKit on Android. A while ago, we started the effort to upstream the Android port of WebKit. For a variety of reasons, this work took longer than anticipated and was never finished. We realize that the incomplete Android port that exists today in WebKit ToT has caused quite a bit of confusion and inconvenience to the project as a whole and we are very sorry for that. Over time, the Android Browser has come to share more and more code with Chrome (both WebKit and Chromium). This approach has a number of advantages for the WebKit community: 1. Android WebKit no longer requires a separate build system because we are able to reuse Chromium’s gyp system for building. 2. Android no longer requires a separate set of WebCore clients, platform abstractions, and embedder APIs because Android shares much of this code with the Chromium port. 3. The Android layout tests results more closely match chromium-linux and more expected results can be shared. We plan to start by setting up a webkit.org build bot that will compile Chromium’s DRT for Android using the Android NDK, SDK and toolchain. We anticipate a reasonably small set of changes to the Chromium port to achieve this. We’re fully committed to maintaining this new flavor of the Chromium port of WebKit and having a build bot up and running as soon as possible will make this an easier task. At the same time, we will be removing the existing incomplete Android port. This includes the Android-specific code in WebCore/platform/android, as well as any code guarded by the PLATFORM(ANDROID) macro. We’re looking forward to a much better collaboration with the WebKit community and we’d be very grateful to receive any feedback on this plan. Thanks, Andrei, Steve, Ben ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Why don't WebKit support the database of geolocation permissions?
Hi, On Wed, Aug 10, 2011 at 9:51 AM, DongWoo Im dw...@samsung.com wrote: Dear Andrei. Thanks for your reply. You said the redundant implementation is an intentional decision to give freedom to browser vendors. You've written the spec. of geolocation, so that must be the intention of the editor. However, I still think that is slightly inefficient. I think this way could be possible. Let's make the database management - read, write, and refer - in WebCore. We can also give freedom to browser vendors to decide the configuration of the database by implementing the port layer. They can decide how long the permissions will live in database, offer the unique interface to the user, or even disable the database. As you say, the database schema will be depend on how the permissions are implemented: Safari grants permissions that expire after a while, while Android and Chromium store permissions until they are explicitly removed by users. Chromium also differentiates between permissions granted to an origin when its content is loaded as the top level document vs when it is loaded in a cross-origin iframe. I am therefore not sure what set of common functionality we could put in WebCore to make the effort worthwhile and actually gain anything. We already have wrappers for SQLite so it's very easy for each embedder to write the permission management code. Thanks, Andrei ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Why don't WebKit support the database of geolocation permissions?
On Mon, Aug 8, 2011 at 11:16 AM, 임동우 dw...@samsung.com wrote: Why don't WebKit support the database of geolocation permissions? (Record the user permission into database, and use it when user revisit the web site.) Most of major browsers who use WebKit are support this kind of feature. Chrome and Safari support this feature, and Android browser as well. And as I know, Mobile Safari in iOS5 may support this. Vendors implement this feature by themselves, because WebKit does not support it, so the implementation and policy are slightly different each other. Some vendors are implemented in porting layer of WebKit, the others are in browser. As I know, in Android, implementation of this feature in porting layer of WebKit. I think we'd better to implement this feature in WebCore. Then we can prevent redundant implementation of each vendors. This is intentional: as you noticed, each browser vendor may chose a different way of managing the Geolocation permissions. To allow for this freedom, I think the Geolocation permissions should not be in WebCore. And, this feature is not violating the Geolocation spec. This statement in the Geolocation spec. is told us that user permission could be preserved. Those permissions that are acquired through the user interface and that are preserved beyond the current browsing session must be revocable and user agents must respect revoked permissions. ( http://dev.w3.org/geo/api/spec-source.html#privacy_for_uas) That is not a specification of how the feature should be implemented, it is just a privacy consideration for implementors of the API. If most of major browsers support this feaure, and users prefer this kind of interaction, then I think there are no reason to hesitate to include this feature into WebKit. I don't really agree. I think it should be left to each WebKit port / embedder to decide if and how to support this feature, so it doesn't belong in WebCore. Thanks, Andrei ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Adding ENABLE_BATTERY_STATUS to WebCore
On Fri, Jun 17, 2011 at 4:21 PM, Darin Fisher da...@chromium.org wrote: On Fri, Jun 17, 2011 at 4:11 AM, Anssi Kostiainen anssi.kostiai...@nokia.com wrote: Hi, On 16.6.2011, at 19.02, ext Darin Fisher wrote: On Thu, Jun 16, 2011 at 5:12 AM, Anssi Kostiainen anssi.kostiai...@nokia.com wrote: On 15.6.2011, at 21.29, ext Darin Fisher wrote: There should probably be a way to poll the current state. Much as you can poll the document.readyState and respond to progress events, it would seem to make sense to have a way to poll the battery state as well as respond to battery state change events. The current design is quite similar to that of the Device Orientation Event. We discussed the polling option but settled on the current design. Let me know if you'd like me to dig into archives for some pointers on that design decision. I'd be curious to read them. Off-hand it seems like device orientation suffers from the same problem. You wouldn't want the application to do too much work that would be discarded once it finds out that the orientation is X instead of Y. I think the design guidelines introduced in the following Mozilla position paper are still valid. In this context, specifically: [[ Device APIs should be asynchronous; in particular, user agents should not have to block on return values of Device API function calls, and Device APIs should be driven by callbacks. http://www.w3.org/2008/security-ws/papers/mozilla.html#asynchronous ]] The proposal wasn't to make blocking APIs that query any devices. Instead, you would be able to get synchronous access to the last known value for a device property (last known battery state, last known device orientation, etc.). In particular, you would get access to the last known value prior to your page being loaded. Synchronous access to this value seems helpful for the reasons stated in this thread. But, let me expand on that for a moment. Suppose an application wanted to know both the battery state and the device orientation before generating its content. It would need to asynchronously query both states before proceeding. That seems quite awkward, especially when the information could be provided synchronously. In the case of device orientation, having such a synchronous property would probably mean having the UA do a lot of wasted work, constantly exercising the underlying hardware just in case some Web app might need this information at start-up. However, I think it's reasonable to expect that Web apps using this API will be built in such a way that they will do work in response to orientation changes, so it's perhaps natural for them to treat the initial orientation the same way. Thanks, Andrei ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Adding ENABLE_BATTERY_STATUS to WebCore
On Wed, Jun 15, 2011 at 5:58 PM, Brett Wilson bre...@chromium.org wrote: On Wed, Jun 15, 2011 at 9:30 AM, Holger Freyther ze...@selfish.org wrote: On 06/15/2011 06:11 PM, laszlo.1.gom...@nokia.com wrote: Hi, The use-case for us is to enable content developers to implement rudimentary power management (e.g. to stop expensive operations on the page, perhaps save state). I'm not sure if this API is really meant for accurately reporting all the possible power management states of the system as Anssi pointed out. Okay, point on complexity taken. My question is what if you want to add complexity, is there something in the event that prevents that (I have no idea about DOM compatibility issues)? Don't get me wrong I think having more device support is great. My other complain was, it is too simple. E.g. 'isPlugged' has no guarantee that the battery is getting charged. Is this a problem? Why would a web page care about whether the battery is being charged when the device is plugged in? Because it would know not to start doing things that drain the battery. For instance, powering up a 3G antenna to download your latest emails could be annoying to users if the battery level is too low. 3G takes quite a bit of power and the device would be in danger of powering down. Thanks, Andrei ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Adding ENABLE_BATTERY_STATUS to WebCore
On Wed, Jun 15, 2011 at 6:08 PM, Alexis Menard alexis.men...@openbossa.org wrote: On Wed, Jun 15, 2011 at 2:02 PM, Andrei Popescu andr...@google.com wrote: On Wed, Jun 15, 2011 at 5:58 PM, Brett Wilson bre...@chromium.org wrote: On Wed, Jun 15, 2011 at 9:30 AM, Holger Freyther ze...@selfish.org wrote: On 06/15/2011 06:11 PM, laszlo.1.gom...@nokia.com wrote: Hi, The use-case for us is to enable content developers to implement rudimentary power management (e.g. to stop expensive operations on the page, perhaps save state). I'm not sure if this API is really meant for accurately reporting all the possible power management states of the system as Anssi pointed out. Okay, point on complexity taken. My question is what if you want to add complexity, is there something in the event that prevents that (I have no idea about DOM compatibility issues)? Don't get me wrong I think having more device support is great. My other complain was, it is too simple. E.g. 'isPlugged' has no guarantee that the battery is getting charged. Is this a problem? Why would a web page care about whether the battery is being charged when the device is plugged in? Because it would know not to start doing things that drain the battery. For instance, powering up a 3G antenna to download your latest emails could be annoying to users if the battery level is too low. 3G takes quite a bit of power and the device would be in danger of powering down. But if the phone is plugged in it can't power down. Most of modern phones don't switch off anymore even if you have the battery low and you play games, surf WiFi, go 3G as soon as you plugged it in. What Brett meant is that it's useless to know that the battery is charging while the phone is plugged in, you just want to know that it will not switch off in any case so you can do whatever you want. Ugh, you're right, I just misunderstood Brett's question :) In fact, as Holger points out, isPlugged actually implies that the battery is being charged. Andrei webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev -- Alexis Menard Software Engineer INdT Recife Brazil ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Clients and the Page constructor
On Wed, Jul 21, 2010 at 8:57 PM, Steve Block stevebl...@google.com wrote: Another argument for the setter is that it makes it easier to inject a mock for testing in response to a LayoutTestController method call, by simply calling the setter again to replace the real client with a mock client. Personally, however, I think that this is somewhat abusing the idea of setting a client. If the real implementation needs to be switched for a mock at runtime in DRT, this should probably be handled by the client itself - so the same client is used throughout the lifetime of the Page. Furthermore, none of the cases that I am familiar with (Geolocation, Device Orientation, speech) require to start in DRT with a real client implementation and then, later, switch to a mock in response to some DRT method call. They all can quite happily pass the mock client pointer in the Page ctor. So the mock injection argument you mention above is for a problem that does not exist in reality. Thanks, Andrei ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Web SQL Database API - openDatabaseSync
Hi, On Fri, Jul 2, 2010 at 2:40 AM, Eric Uhrhane er...@google.com wrote: I doubt that it's been pushed to any Android phone yet. It only went into webkit in the past couple of months, and there's a bit of lag as they incorporate new code. You'd have to ask Android folks when they plan to ship it. Async Web SQL Database is available on Android since version 2.0. Sync Web SQL Database and Web Workers are not currently available on Android (not even on 2.2). Thanks, Andrei ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Fwd: Review queue needs love
Hi, On Fri, Jun 19, 2009 at 3:03 AM, Eric Seidele...@webkit.org wrote: The other 24 remaining patches consist of 6 Gtk patches, 3 Chromium patches, and a bunch of huge new feature patches. No quite. The following two are rather small patches to common code (appcache and database): https://bugs.webkit.org/show_bug.cgi?id=22700 https://bugs.webkit.org/show_bug.cgi?id=25711 I think Alexey promised to look at them. Thanks, Andrei ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] setting a size limit for Application Cache
Hi, I was recently looking at https://bugs.webkit.org/show_bug.cgi?id=22700 I have a small patch that attempts to fix this issue by 1. allowing the ChromeClient implementers to decide what the size limit should be, 2. evicting caches (in LRU order) from the database when the size limit is reached and a new cache needs to be saved. After an initial discussion with Alexey Proskuryakov on IRC, we agreed to ask webkit-dev for advice on this matter: is LRU eviction the correct thing to do? It seems clear that the intended usage of Application Cache is to act as a repository for Web applications that can be used offline. However, when the disk space allowed for this is completely used up, would it be ok to make room for new apps by automatically evicting existing ones? The advantage of this is that it allows this feature to function without any UI at all. The drawback is that some apps would suddenly stop working offline. The alternative is to simply throw an error when the size limit is reached and expect the UA to provide some UI that allows users to free space by uninstalling existing apps. However, having another setting for this may turn out to be inconvenient (it's hard to discover and increases the burden on users who already have to deal with cookies, normal HTTP cache, databases, geolocation, etc). Many thanks, Andrei ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Geolocation API in WebKit
Hello, I would like to know if there is anyone working on adding WebKit support for the Geolocation API as defined in this W3C draft: http://dev.w3.org/geo/api/spec-source.html I am asking because our team would like to help with this. If nobody is working on it, we'd like to start the development ourselves. Many thanks, Andrei ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
