Re: [webkit-dev] New feature : Network Information API
Hi Gyuyoung, This is great news! Can I ask you also to take a look at the editor's draft http://dev.w3.org/2009/dap/netinfo/#connection-interface so that you can keep it in mind as you design the feature, since the draft will at some point likely become the next TR. Cheers John On Thu, Dec 1, 2011 at 9:27 AM, Gyuyoung Kim gyuyoung@samsung.comwrote: Hello WebKit folks, I'd like to introduce new feature - Network Information API. This feature is to provide an interface for Web Applications to access the underlying network information of device. In Web Application case, they need to know what current network interface it uses. Because, it is important to know current network backbone(wifi, 3g, 4G and so on) in mobile domain. Thus, Web Application can let user know whether current network bearer is 3G or wifi via this new functionality. In addition, in streaming service case, Web Application can control content resolution according to kind of network. Spec : http://www.w3.org/TR/netinfo-api/ I file a bug for this feature. Bug 73528. ( https://bugs.webkit.org/show_bug.cgi?id=73528). However, submitted patch is still prototype. I will improve the submitted patch according to advices or opinions. Cheers, Gyuyoung. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] pageDestroyed and disconnectFrame
Can anybody explain the differences between Frame::pageDestroyed() and DOMWindow::disconnectFrame()? It seems that these notifications can be called in either order (e.g. pageDestroyed() from FrameLoader and ~Page, and disconnectFrame from ~Frame). Is there a method that is guaranteed to be called before both pageDestroyed() and disconnectFrame()? In my bug fix, https://bugs.webkit.org/show_bug.cgi?id=52877 , I am hooking into both notifications to perform the same disconnect logic, but I wonder if there is a simpler way to do things? Many thanks John ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] JSRetainPtr and JSStringRef
Hello I'm looking at adding a method on the LayoutTestController in DumpRenderTree that will return a string. I see that some methods there return JSRetainPtrJSStringRef and some just return JSStringRef. Can anybody comment on when it is appropriate to return JSRetainPtr vs plain JSStringRef? Many thanks John ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Client-based Geolocation
I've been working on getting Chromium's WebKit layer to support client-based Geolocation. This means that a class in the Chromium WebKit layer implements the WebCore interface GeolocationClient, and an instance of this class is provided to the Page constructor (by means of PageClients). This is a neat way of keeping the platform specific code in the WebKit layer (rather than in WebCore, where the existing GeolocationService and platform code is). The design of client-based geolocation feels very clean and I think it is easier to understand as it follows a similar pattern to other existing client-based designs (e.g. speech, device orientation, device motion). It would be great if, ultimately, we could remove the non-client-based geolocation code from WebCore (I already have plans to do this for Chromium's WebKit layer). Such a removal would make the WebCore code more readable because the #if ENABLE(CLIENT_BASED_GEOLOCATION) preprocessor directives would go away, more understandable because there would be less code, and more maintainable because we would only need to fix bugs in one code path, rather than two. It seems that Android, Qt and GTK currently implement the non-client-based design. Is anybody working, or interested in working, on migrating these platforms to the client-based design? Thanks John ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
