Re: [webkit-dev] Add a set of new APIs for the Custom Scheme and Content Handler.
On Nov 28, 2011, at 8:54 PM, DongWoo Im wrote: Hi webkit-dev, I would like to let you know that I'm planning to add a set of new APIs for the Custom Scheme and Content Handler. ** Specification link : http://dev.w3.org/html5/spec/Overview.html#custom-handlers ** Bugs - Custom Scheme Handler : https://bugs.webkit.org/show_bug.cgi?id=73176 - Custom Content Handler : https://bugs.webkit.org/show_bug.cgi?id=73177 Originally, there just defined a kind of set functions, 'registerProtocolHandler' and 'registerContentHandler'. In this patch (73176, 73177), two more APIs are added per each handler. (1) an API if a specific URL has been registered or not: 'isProtocolHandlerRegistered' and 'isContentHandlerRegistered'. (2) an API to remove a registered URL: 'unregisterProtocolHandler' and 'unregisterContentHandler'. I would think these additional APIs could make the Custom Handler more useful. Also, I would like to roll back in the implementation of 'registerContentHandler', which was rolled out earlier. This API was landed in r50477, but it rolled out in r62834 because the implementation was not completed in any WebKit port. I will implement this API in the EFL port to support the 'registerContentHandler'. It would be appreciated if you let me know how we could roll back in the 'registerContentHandler'. I think you should propose these to the relevant standards group before adding them to WebKit (either WHATWG or HTML WG). They do not seem valuable enough to add as WebKit-only extensions. And other vendors may be against them, for example, on privacy grounds. So we should discuss with the standards group first. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] CORS Access-Control-Expose-Headers not supported by webkit?
On Nov 21, 2011, at 2:00 PM, Ojan Vafai wrote: Just curious, how is it different from Access-Control-Allow-Headers? Access-Control-Allow-Headers is a response header which signals that specific custom request headers may be sent by the client. http://www.w3.org/TR/access-control/#access-control-allow-headers-response-he Access-Control-Expose-Headers is a response header that indicates which response headers may safely be exposed to the client. http://www.w3.org/TR/access-control/#access-control-expose-headers-response-h Regards, Maciej On Mon, Nov 21, 2011 at 1:47 PM, Eric Seidel e...@webkit.org wrote: This is where you would look: http://trac.webkit.org/browser/trunk/Source/WebCore/loader/DocumentThreadableLoader.cpp You might also find these documents useful: http://www.webkit.org/coding/contributing.html http://www.webkit.org/quality/reporting.html http://www.webkit.org/quality/testwriting.html -eric On Mon, Nov 21, 2011 at 1:39 PM, Adam Barth aba...@webkit.org wrote: Patches welcome. Adam On Mon, Nov 21, 2011 at 1:16 PM, Andy Hou andye...@google.com wrote: Hi Webkit Developers, Are there plans to support the CORS Access-Control-Expose-Headers in webkit? It's been supported by Firefox for a few months now. There's a webkit bug filed. It would be great if someone could take a look at this. Thanks, - Andy ___ 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 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 mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Add a set of new APIs for the Custom Scheme and Content Handler.
Looks like I was mistaken and misread the spec, so I withdraw this comment. Do other browsers that implement the register functions also implement the related isRegistered and unregister functions? - Maciej On Nov 29, 2011, at 12:08 AM, Maciej Stachowiak wrote: On Nov 28, 2011, at 8:54 PM, DongWoo Im wrote: Hi webkit-dev, I would like to let you know that I'm planning to add a set of new APIs for the Custom Scheme and Content Handler. ** Specification link : http://dev.w3.org/html5/spec/Overview.html#custom-handlers ** Bugs - Custom Scheme Handler : https://bugs.webkit.org/show_bug.cgi?id=73176 - Custom Content Handler : https://bugs.webkit.org/show_bug.cgi?id=73177 Originally, there just defined a kind of set functions, 'registerProtocolHandler' and 'registerContentHandler'. In this patch (73176, 73177), two more APIs are added per each handler. (1) an API if a specific URL has been registered or not: 'isProtocolHandlerRegistered' and 'isContentHandlerRegistered'. (2) an API to remove a registered URL: 'unregisterProtocolHandler' and 'unregisterContentHandler'. I would think these additional APIs could make the Custom Handler more useful. Also, I would like to roll back in the implementation of 'registerContentHandler', which was rolled out earlier. This API was landed in r50477, but it rolled out in r62834 because the implementation was not completed in any WebKit port. I will implement this API in the EFL port to support the 'registerContentHandler'. It would be appreciated if you let me know how we could roll back in the 'registerContentHandler'. I think you should propose these to the relevant standards group before adding them to WebKit (either WHATWG or HTML WG). They do not seem valuable enough to add as WebKit-only extensions. And other vendors may be against them, for example, on privacy grounds. So we should discuss with the standards group first. Regards, Maciej ___ 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] Reg. Use of CAIRO_EXTEND_REPEAT
Can anybody explain what is the use of 'cairo_pattern_set_extend(pattern. get(), CAIRO_EXTEND_PAD);' in http://trac.webkit.org/browser/trunk/Source/WebCore/platform/graphics/cairo/PlatformContextCairo.cpp ..? Regards, Vicky. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] squirrefish extreme on Arm.
Hi all. I have been studing about squirrefish extreme for last several days but can't find answers to several quations I need. 1. How can I dump compiling process? For instanance in GCC I can compile with -da -fdump_tree_all and then get all passes up to assembler generation. So is there any way to do the same on squirrefish extreme ? I wanna to see which optimizations are works in each state. And finaly how can I get bytecode from my source. I built webkitv with --debug option and tried to run ./jsc-3 sunspider -d, but it didn't give bytecode -- View this message in context: http://old.nabble.com/squirrefish-extreme-on-Arm.-tp32876913p32880353.html Sent from the Webkit mailing list archive at Nabble.com. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Add a set of new APIs for the Custom Scheme and Content Handler.
On Tue, Nov 29, 2011 at 17:59, Maciej Stachowiak m...@apple.com wrote: Looks like I was mistaken and misread the spec, so I withdraw this comment. Do other browsers that implement the register functions also implement the related isRegistered and unregister functions? Opera dev team has mentioned about it that they did not implemented yet: http://my.opera.com/ODIN/blog/2011/11/07/custom-protocol-and-content-handlers. However, I would envisage that they would check in the mentioned APIs soon or later. Also, by reading the spec and using my general sense, it seems all right going into the development of those two APIs in order to form a full functionality. When one can register protocol/content handler, then he would also like to check it if it's registered, and then later unregister them. In short, I don't think it is a bad idea to implement these new APIs in the WebKit at this right moment. Soo-Hyun - Maciej On Nov 29, 2011, at 12:08 AM, Maciej Stachowiak wrote: On Nov 28, 2011, at 8:54 PM, DongWoo Im wrote: Hi webkit-dev, I would like to let you know that I'm planning to add a set of new APIs for the Custom Scheme and Content Handler. ** Specification link : http://dev.w3.org/html5/spec/Overview.html#custom-handlers ** Bugs - Custom Scheme Handler : https://bugs.webkit.org/show_bug.cgi?id=73176 - Custom Content Handler : https://bugs.webkit.org/show_bug.cgi?id=73177 Originally, there just defined a kind of set functions, 'registerProtocolHandler' and 'registerContentHandler'. In this patch (73176, 73177), two more APIs are added per each handler. (1) an API if a specific URL has been registered or not: 'isProtocolHandlerRegistered' and 'isContentHandlerRegistered'. (2) an API to remove a registered URL: 'unregisterProtocolHandler' and 'unregisterContentHandler'. I would think these additional APIs could make the Custom Handler more useful. Also, I would like to roll back in the implementation of 'registerContentHandler', which was rolled out earlier. This API was landed in r50477, but it rolled out in r62834 because the implementation was not completed in any WebKit port. I will implement this API in the EFL port to support the 'registerContentHandler'. It would be appreciated if you let me know how we could roll back in the 'registerContentHandler'. I think you should propose these to the relevant standards group before adding them to WebKit (either WHATWG or HTML WG). They do not seem valuable enough to add as WebKit-only extensions. And other vendors may be against them, for example, on privacy grounds. So we should discuss with the standards group first. Regards, Maciej ___ 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 mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Simplifying hub classes (was Cleaning up directories in WebCore)
On Nov 20, 2011, at 8:55 PM, Adam Barth wrote: On Sun, Nov 20, 2011 at 8:36 PM, Hajime Morrita morr...@google.com wrote: One traditional pattern is to split a big class into a set small classes plus a hub class like how Adam has done for original Frame. ^^^ The work to split up Frame was largely done before I was involved with the project. Maciej proposed this pattern. I am not sure who all the people who implemented it were; I remember doing a lot of it. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] squirrefish extreme on Arm.
-d should work fine on ARM - check your build settings, is any #ifndef NDEBUG code getting built? In addition there are a set of switches in dfg/DFGCommon.h that include ones to enable further dumping of the intermediate representation. G. On Nov 29, 2011, at 2:51 AM, vahagvahag wrote: Hi all. I have been studing about squirrefish extreme for last several days but can't find answers to several quations I need. 1. How can I dump compiling process? For instanance in GCC I can compile with -da -fdump_tree_all and then get all passes up to assembler generation. So is there any way to do the same on squirrefish extreme ? I wanna to see which optimizations are works in each state. And finaly how can I get bytecode from my source. I built webkitv with --debug option and tried to run ./jsc-3 sunspider -d, but it didn't give bytecode -- View this message in context: http://old.nabble.com/squirrefish-extreme-on-Arm.-tp32876913p32880353.html Sent from the Webkit mailing list archive at Nabble.com. ___ 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] About IDL files
I have some idl files to define some new javascript object interfaces. I am expected to implement some plugins for them.Is it possible to auto generate some stub code using the idl files?Or do I have to implement those plugins which support those javascript objects based on idl files one by one?How can I make good use of those idl files? Thanks! Jeffrey ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] How to use IDL files?
I have some idl files to define some new javascript object interfaces. I am expected to implement some plugins for them. Is it possible to auto generate some stub code using the idl files? Or do I have to implement those plugins which support those javascript objects based on idl files one by one? How can I make good use of those idl files? Thanks! Jeffrey ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Using C++ constant local variables in WebKit
On Nov 28, 2011, at 1:38 PM, David Kilzer wrote: In a discussion on Bug 71921, Antti, Darin Adler and I started a discussion about using C++ constant pointers in WebKit. Does the WebKit community have a consensus opinion on the matter? I thought we were discussing local variables in general, not pointer-typed ones specifically. * Pros - Documents use of variable. I would say “documents the fact that the variable’s value is not changed”. I think it’s overstating things to say it “documents use”. - Prevents misuse of variable in a later patch (by a different author) through enforcement of const-ness. Prevents one specific type of misuse: Setting the variable to another value. And that may not be misuse despite the fact that the original author didn’t plan on changing it. - May help compiler optimize code. (We weren't sure whether modern compilers do this on their own or not.) Doesn’t. * Cons - Darin Adler doesn't ever recall fixing a bug in WebKit where a constant pointer would have helped. While true, not really a “con”; just weakens the “pro” argument above that this prevents misuse. - Slightly more verbose syntax for constant pointers to a constant string (const char * const pointer;) or even a constant pointer to a mutable string (char * const pointer;). Not sure this is a con. Just stating what the C++ syntax. This is the con I am aware of: - Less brief than omitting const. I’m not strongly opposed to using const more, but I am mildly opposed to it. -- Darin___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Using C++ constant local variables in WebKit
As I stated on the other thread, I'm against using const pointers. However, I see benefits in using const local variables. On Tue, Nov 29, 2011 at 6:19 PM, Darin Adler da...@apple.com wrote: I thought we were discussing local variables in general, not pointer-typed ones specifically. * Pros - Documents use of variable. I would say “documents the fact that the variable’s value is not changed”. I think it’s overstating things to say it “documents use”. Well, we can always call some function with a pointer to it, and the callee can const_cast it. Having said that, declaring it explicitly const makes it clear that it's not intended to be used like that. For example, when I was writing a patch for https://bugs.webkit.org/show_bug.cgi?id=69267, I encountered a line: resolver.setPosition(oldEnd); at http://trac.webkit.org/browser/trunk/Source/WebCore/rendering/RenderBlockLineLayout.cpp?rev=101180#L1287 It took me a while before I figured out that oldEnd is never modified and I can do some optimizations here. Presumably I still have to manually look for all lines of code that touches oldEnd even if oldEnd was const due to const_cast. However, it would have at least signaled me the intent. - Prevents misuse of variable in a later patch (by a different author) through enforcement of const-ness. Prevents one specific type of misuse: Setting the variable to another value. And that may not be misuse despite the fact that the original author didn’t plan on changing it. Right, but it tells us the intent of the author, and appears to be useful even if the variable started with prefixes like old, original, and previous. - Ryosuke ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Using C++ constant local variables in WebKit
On Tue, Nov 29, 2011 at 6:42 PM, Ryosuke Niwa rn...@webkit.org wrote: - Prevents misuse of variable in a later patch (by a different author) through enforcement of const-ness. Prevents one specific type of misuse: Setting the variable to another value. And that may not be misuse despite the fact that the original author didn’t plan on changing it. Right, but it tells us the intent of the author, and appears to be useful even if the variable started with prefixes like old, original, and previous. I'll add that I'd much prefer seeing a const in front of a local variable over seeing a comment like This variable shouldn't be modified. - Ryosuke ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Add a set of new APIs for the Custom Scheme and Content Handler.
On Wed, Nov 30, 2011 at 02:05, David Levin le...@chromium.org wrote: Please don't rollback in the change that was rolled out. Feel free to use it as a guide but that patch was flawed in that it exposed an api which did nothing on some platforms which would break feature detection. dave Sure - there's no problem using the rolled-out codes as a guide as you mentioned. Cheers, Soo-Hyun ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] What is the reason for changing JavaScript parser from bison parser(LR) to Top-To-Down Recursion parser?
Hello everyone, I am researching WEBKIT and coming up against difficulty about Javascript parser。As I Know, WEBKIT of old version uses the bison parser to interpret javascript code. But WEBKIT of recently version doesn't uses bison parser. Instead, WEBKIT of recently version uses Top-To-Down Recursion parser. I have some details to add. 1) WEBKIT using bison parser has a source file named Grammar.cpp. 2) I know WEBKIT with 38688 version number uses bison parser. I hope someone can give me some explanation, thanks.___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
