Eric Seidel | 2 Apr 01:28 2012

Re: Feature Announcement: Adding <iframe seamless>

Adding ENABLE, skipping tests, and reverting any non-passing tests,
proved complicated.  So I've reverted my work on trunk:
http://trac.webkit.org/changeset/112820

and I'll be doing my <iframe seamless> work on GitHub.  Interested
parties can follow my fork/branch here:
https://github.com/eseidel/webkit/compare/master...seamless

Thank you all for your feedback.

-eric

On Fri, Mar 30, 2012 at 8:11 PM, Darin Fisher <darin <at> chromium.org> wrote:
> [Oops, I meant to reply on list.]
>
> I think it is a risky practice for WebKit to have half-baked "webkit"
> prefixed
> features enabled by default on trunk.  It puts the burden on all WebKit
> ports
> to know which features are half-baked, whereas individual authors of new
> features would know best how stable their features are.
>
> Once a port ships a feature, however baked the feature may be, if it becomes
> popular (to some degree), we risk having to support it.  I don't think web
> developers necessarily understand that they should regard "webkit" prefixed
> features as buyer-beware given that there are so many "webkit" prefixed
> features that we all tell developers to use.  How can developers tell the
> difference between the stable ones and unstable ones?
>
> It seems safest to ENABLE-guard all half-baked features on trunk, vendor
(Continue reading)

Pavel Feldman | 2 Apr 11:18 2012

Blog post "Announcing Remote Debugging Protocol v1.0"

Hi guys,


I'd like to announce the remote debugging protocol v1 where we define backward compatibility and commit to supporting it in a blog post. The draft can be found here: http://www.webkit.org/blog/?p=1875&preview=true. Pasting its content for the sake of accessibility below.

Regards
Pavel

Announcing Remote Debugging Protocol v1.0

Posted by Pavel Feldman on Monday, April 2nd, 2012 at 2:13 am

It has been almost a year since we announced the support for WebKit remote debugging. It is now officially supported by BlackBerry PlayBook and in Chrome for Android. Latest version of Chrome introduces new extensions API that exposes it to the in-browser clients as well.

We are happy to announce that remote debugging protocol version is now v1.0, and we can commit to supporting it and maintain its backward compatibility. Since we receive a lot of questions on the remote debugging from the port owners, protocol clients and WebKit contributors, I’d like to provide a brief remote debugging 101 here. It will provide answers to the questions such as:

  • What is the structure of the remote debugging message?
  • Is there a documentation of the protocol?
  • Is remote debugging protocol versioned? How is backward compatibility defined?
  • What do I need to do in order to support remote debugging with standard Web Inspector front-end in my WebKit port?

Protocol definition

Protocol schema

WebKit is using JSON-RPC 2.0 protocol for the remote debugging. Clients send commands to the backend and receive responses in return. Backend can generate notifications upon particular events on its own. Commands, responses and notifications are all JSON-serialized objects.

The remote debugging protocol schema is defined by the Inspector.json. Protocol documentation along with parts of the inspector source code is generated from that file. We group commands and events of a particular nature into domains such as DOMDebuggerNetwork for the convenience.

Commands and notifications

Here is a sample command that is setting a breakpoint:

{ "id": 10, // <-- command sequence number generated by the caller "method": "Debugger.setBreakpointByUrl", // <-- protocol method "params": { // <-- named parameters map "lineNumber": 23, "url": "http://www.webkit.org/index.html" } }

Backend responds to all the commands either with the result of with the error message. For the above command, the backend will generate the following response:

{ "id": 10, // <-- same id as in the command "result": { // <-- command result "breakpointId": "http://www.webkit.org/index.html:23", "locations": [ { "lineNumber": 23, "columnNumber": 10 } ] } }

Notifications don’t have identifiers. For example, when JavaScript source is evaluated in the virtual machine, following notification is sent to the client:

{ "method": "Debugger.scriptParsed", // <-- notification method "params": { // <--notification parameters "scriptId": "15", "url": "http://www.webkit.org/index.html", "startLine": 22, "startColumn": 12, "endLine": 33, "endColumn": 4 } }

Complete list of the protocol methods for the v1.0 of the protocol can be found here.

Hidden entities

If you look at the Inspector.json file that defines the protocol schema, you will notice that some of the protocol entities (domains, commands and parameters) are marked as “hidden”. We don’t generate documentation for such entities. Although one can technically use them, we are not yet ready to commit to maintaining their backward compatibility. As the protocol matures, we will be polishing these entities and making them public.

Protocol versioning and backward compatibility

With the revision r106352, we updated the protocol version to v1.0. All subsequent v1.* versions of the protocol are going to be backward compatible with v1.0. Protocol backward compatibility is defined as follows:

  • No commands or notifications are removed from the protocol.
  • No required parameters are added to the commands.
  • No required parameters are removed from command responses or notifications.

We do not anticipate any breaking changes to the protocol any time soon (years), but we leave this possibility to ourselves. We will flip the major version component when such change comes. You can find documentation of all of the versions of the protocol including the tip-of-tree version here.

Enabling remote debugging on your WebKit port

Using Web Inspector front-end for remote debugging

You can either come up with an alternate remote debugging client or use the default Web Inspector front-end. Web Inspector front-end is capable of interacting with the backend over the WebSocket transport layer. In the remote mode, WebSocket frames will be carrying the protocol messages. WebSocket connection is dedicated, there can only be one client attached to the WebKit page at a time. To see how that works, you can run the Chrome Canary with the following command line flag:

chrome --remote-debugging-port=9222

Then open any WebKit-based browser and navigate to http://localhost:9222. You will see that initiating the remote debugging sessions loads the front-end from the browser. This is possible because Chrome bundles the Web Inspector front-end and implemented a small HTTP server for serving these files. This is not always possible in case of embedded solutions, but since Web Inspector front-end is just a web app, can be loaded it from any server. Try running Chrome Canary as

chrome --remote-debugging-port=9222 --remote-debugging-frontend="http://trac.webkit.org/export/head/trunk/Source/WebCore/inspector/front-end/inspector.html".

It will tell Chrome to use trac.webkit.org as a front-end app. Chrome for Android team uploads a version of Web Inspector front-end to appspot.com with each public build and points to it from the remote debugging page. You can download that site, change the front-end URL to the local one and do remote debugging with no internet connection at all.

Running WebSocket server in your port

In order to use default Web Inspector front-end for the remote debugging of your WebKit port, you need to implement a small web server supporting WebSocket specification. We did not make this server code a part of the WebCore because it is up to the embedder to be listening for external connections and discover the inspectable pages. In some cases, socket should operate in a different process than the WebKit is operating in. For example, in Chrome, the socket is opened by the browser process, and browser dispatches protocol messages to the corresponding WebKit instances running in the renderer processes. I’ll list a number of WebSocket server implementations below.

  • To start debugging session, call InspectorController::connectFrontend(). In case of WebSocket implementation, it is typically done upon accepting WebSocket connection.
  • To end debugging session, call InspectorController::disconnectFrontend().  This should be done upon WebSocket connection termination.
  • Call InspectorController::dispatchMessageFromFrontend(message) for each WebSocket frame you receive.
  • Issue WebSocket frame for each InspectorClient::sendMessageToFrontend call you get from the WebCore

See Chrome light http server and devtools handler for reference. There is an effort that adds generic WebSocket server for inspector to WebKit2. You can track these bugs to follow the discussion or borrow the code for your own port.



_______________________________________________
webkit-dev mailing list
webkit-dev <at> lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Keishi Hattori | 3 Apr 08:34 2012

Disabling ENABLE_DATALIST for now

Hi everyone,

Right now ENABLE_DATALIST is on for all ports, but I will be turning
it off because
- All ports except blackberry don't have a UI
- We need to hide the fallback content if ENABLE_DATALIST is on

If this change will cause problems, please let me know.
https://bugs.webkit.org/show_bug.cgi?id=82871

Thanks,
Keishi
Iker Perez de Albeniz | 3 Apr 10:02 2012

RegExp on JSStaticFunction

Hi,


I have estarted a personal project and i am new on wbkit development. I have a question about the posibility of using regular expression on JSStaticFunction struct name.. so i can resolve every methos of a class with an unique funcrtion..

My idea is to hace a fucntion that conects to a socket where the "core" of the class is available.. so i can do something like..


static JSValueRef myclass_mymethod(JSContextRef context,
                       JSObjectRef function,
                       JSObjectRef thisObject,
                       size_t argumentCount,
                       const JSValueRef arguments[],
                       JSValueRef *exception)
{
   // get the name of the funcion called
   //open a socket and call to a REST service
}


static const JSStaticFunction class_staticfuncs[] ={
  { ".*", myclass_mymethod, kJSPropertyAttributeReadOnly },
  { NULL, NULL, 0 }
};

The idea is to create a bridge betwing JS and a core accesible via sockets/Json..


Regards. 
_______________________________________________
webkit-dev mailing list
webkit-dev <at> lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Geoffrey Garen | 3 Apr 18:46 2012
Picon

Re: RegExp on JSStaticFunction

JavaScript doesn't have a concept of "intercept any method invocation". However, it does have a concept of
"intercept any property access". I believe you could accomplish what you want by implementing a
catch-all JSObjectGetPropertyCallback that created the necessary function objects on the fly, and
cached them.

Geoff

On Apr 3, 2012, at 1:02 AM, Iker Perez de Albeniz wrote:

> Hi,
> 
> I have estarted a personal project and i am new on wbkit development. I have a question about the posibility
of using regular expression on JSStaticFunction struct name.. so i can resolve every methos of a class
with an unique funcrtion..
> 
> My idea is to hace a fucntion that conects to a socket where the "core" of the class is available.. so i can do
something like..
> 
> 
> static JSValueRef myclass_mymethod(JSContextRef context,
>                        JSObjectRef function,
>                        JSObjectRef thisObject,
>                        size_t argumentCount,
>                        const JSValueRef arguments[],
>                        JSValueRef *exception)
> {
>    // get the name of the funcion called
>    //open a socket and call to a REST service
> }
> 
> 
> static const JSStaticFunction class_staticfuncs[] ={
>   { ".*", myclass_mymethod, kJSPropertyAttributeReadOnly },
>   { NULL, NULL, 0 }
> };
> 
> The idea is to create a bridge betwing JS and a core accesible via sockets/Json..
> 
> 
> Regards. 
> _______________________________________________
> webkit-dev mailing list
> webkit-dev <at> lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Jochen Eisinger | 4 Apr 10:31 2012

feature proposal: restricting window.blur/focus

Hey,


Firefox restricts the use of window.blur() and window.focus() (by default). window.blur() is just doing nothing, and window.focus() only works if the caller is running in the same window.

Should we implement similar rules for WebKit? The purpose of this is to make pop-unders more difficult to achieve.

I think this can be implemented in such a way the the chrome implementation which is doing the actual focusing/bluring anyway has enough information to let each port control what they want to do.

wdyt?

-jochen
_______________________________________________
webkit-dev mailing list
webkit-dev <at> lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Iker Perez de Albeniz | 4 Apr 16:36 2012

Re: RegExp on JSStaticFunction

I will try it. 

Thanks.

El 3 de abril de 2012 18:46, Geoffrey Garen <ggaren <at> apple.com> escribió:
JavaScript doesn't have a concept of "intercept any method invocation". However, it does have a concept of "intercept any property access". I believe you could accomplish what you want by implementing a catch-all JSObjectGetPropertyCallback that created the necessary function objects on the fly, and cached them.

Geoff

On Apr 3, 2012, at 1:02 AM, Iker Perez de Albeniz wrote:

> Hi,
>
> I have estarted a personal project and i am new on wbkit development. I have a question about the posibility of using regular expression on JSStaticFunction struct name.. so i can resolve every methos of a class with an unique funcrtion..
>
> My idea is to hace a fucntion that conects to a socket where the "core" of the class is available.. so i can do something like..
>
>
> static JSValueRef myclass_mymethod(JSContextRef context,
>                        JSObjectRef function,
>                        JSObjectRef thisObject,
>                        size_t argumentCount,
>                        const JSValueRef arguments[],
>                        JSValueRef *exception)
> {
>    // get the name of the funcion called
>    //open a socket and call to a REST service
> }
>
>
> static const JSStaticFunction class_staticfuncs[] ={
>   { ".*", myclass_mymethod, kJSPropertyAttributeReadOnly },
>   { NULL, NULL, 0 }
> };
>
> The idea is to create a bridge betwing JS and a core accesible via sockets/Json..
>
>
> Regards.
> _______________________________________________
> webkit-dev mailing list
> webkit-dev <at> lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


_______________________________________________
webkit-dev mailing list
webkit-dev <at> lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
David Dorwin | 4 Apr 18:55 2012

Adding Encrypted Media Extensions

Hi WebKit!

I plan to add the Encrypted Media Extensions to the media elements. The extensions allow web applications using <audio> and <video> to control key exchange. The extensions will be behind the ENCRYPTED_MEDIA feature define. The feature is tracked as https://bugs.webkit.org/show_bug.cgi?id=82968.

Implementation will be based on the draft proposal at http://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media.html, which was published jointly by Google, Microsoft, and Netflix [1]. It appears a Media Task Force will be taking this on to produce a Working Draft [2]. Having an implementation will allow us to include implementation experience in the development of the draft.

As described in the proposal, several new methods and events are added to HTMLMediaElement and a new keySystem parameter and attribute are added to canPlayType() and HTMLSourceElement, respectively. As with much of the media stack, most of the functionality will be implemented within the various ports. ENCRYPTED_MEDIA will be enabled for the Chromium port and covered by its buildbot.

Regards,
David

_______________________________________________
webkit-dev mailing list
webkit-dev <at> lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Oliver Hunt | 4 Apr 19:37 2012
Picon

Re: Adding Encrypted Media Extensions

Last I saw, there hadn't been any attempt to actually define how the content is encrypted.  Has that changed?  If it hasn't how do we get interoperable implementations?  The only way for this spec to not break the openness of <video> and <audio> is for the encryption algorithm to be completely defined in the spec.

--Oliver

On Apr 4, 2012, at 9:55 AM, David Dorwin wrote:

Hi WebKit!

I plan to add the Encrypted Media Extensions to the media elements. The extensions allow web applications using <audio> and <video> to control key exchange. The extensions will be behind the ENCRYPTED_MEDIA feature define. The feature is tracked as https://bugs.webkit.org/show_bug.cgi?id=82968.

Implementation will be based on the draft proposal at http://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media.html, which was published jointly by Google, Microsoft, and Netflix [1]. It appears a Media Task Force will be taking this on to produce a Working Draft [2]. Having an implementation will allow us to include implementation experience in the development of the draft.

As described in the proposal, several new methods and events are added to HTMLMediaElement and a new keySystem parameter and attribute are added to canPlayType() and HTMLSourceElement, respectively. As with much of the media stack, most of the functionality will be implemented within the various ports. ENCRYPTED_MEDIA will be enabled for the Chromium port and covered by its buildbot.

Regards,
David

_______________________________________________
webkit-dev mailing list
webkit-dev <at> lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

_______________________________________________
webkit-dev mailing list
webkit-dev <at> lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Oliver Hunt | 4 Apr 19:38 2012
Picon

Re: feature proposal: restricting window.blur/focus

I am all for this change, but a not insubstantial part of that is my general hate for anything other than me
ever changing the focused window and/or element.

--Oliver

On Apr 4, 2012, at 1:31 AM, Jochen Eisinger wrote:

> Hey,
> 
> Firefox restricts the use of window.blur() and window.focus() (by default). window.blur() is just
doing nothing, and window.focus() only works if the caller is running in the same window.
> 
> Should we implement similar rules for WebKit? The purpose of this is to make pop-unders more difficult to achieve.
> 
> I think this can be implemented in such a way the the chrome implementation which is doing the actual
focusing/bluring anyway has enough information to let each port control what they want to do.
> 
> wdyt?
> 
> -jochen
> _______________________________________________
> webkit-dev mailing list
> webkit-dev <at> lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Gmane