Re: [webkit-dev] Adding ENABLE_CONTACTS to WebCore
On Mon, Jun 27, 2011 at 5:49 PM, Ojan Vafai o...@chromium.org wrote: Can you give an example of a smooth UI that you'd need the more complex API for? When I think of the existing mail and chat apps in iOS/Android that I've use, input type=contacts could give just as smooth a UI as the existing apps, it's just on the browser side to make the UI good instead of on the web developer side. This has lots of follow-on advantages too: - Browser-provided UI is consistent for the user WRT the OS (see file pickers). Your app would need to guess to match the visual and interaction style. - Browsers can handle all of this with much less code on your part. The latency involved in building and sending the custom UI makes for a bad experience, and is it work you really want to be biting off for your app? - A11y, focus management, and all the rest with Just Work (TM). On Mon, Jun 27, 2011 at 3:37 AM, Alex Nicolaou anico...@google.comwrote: A user agent defined solution will make apps like mail, chat, Facebook, and so on all feel awful in safari versus installing a native app. It's like j2me all over again unless the website can provide a smooth ui. Alex On Friday, June 24, 2011, Ojan Vafai o...@chromium.org wrote: Is there a document that lists the use-cases for this API? I couldn't find anything from a quick glance through the DAP working group's mailing list archive. A list of use-cases would help evaluate whether this is the best API. At first glance, it strikes me that something like input type=contacts would meet the uses-cases I can think of better. Ojan On Thu, Jun 23, 2011 at 11:28 PM, 김동관 donggwan@samsung.com wrote: Hi webkit-dev! I wanted to let you know that I plan to add Contacts API support to WebKit. This API is a new feature that is published by W3C. The Device APIs Working Group of W3C has just released a Last Call Working Draft of its Contacts API: http://www.w3.org/TR/2011/WD-contacts-api-20110616/ I'm going to commit patch for Contacts API implementation very soon. This support will be behind the ENABLE_CONTACTS feature define. See: https://bugs.webkit.org/show_bug.cgi?id=63223 We'll be setting up a buildbot to track then ENABLE_CONTACTS build shortly. We expect this feature to be eventually enabled by all ports. Looking forward to your comments. Thank you. Donggwan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev -- -- Try Gmail Offline for Chrome http://goto.ext.google.com/fastgmail-chrome , and send me your complaints! ___ 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] The case for disallowing alerts in unload, redux
On Mon, Jun 27, 2011 at 15:36, Ojan Vafai o...@chromium.org wrote: On Mon, Jun 27, 2011 at 3:17 PM, Alexey Proskuryakov a...@webkit.org wrote: 27.06.2011, в 14:03, Darin Fisher написал(а): I think we can make this behavior a Setting, and then certainly each embedder of WebKit can decide how prominently to surface this option. For Chrome, we'll probably either make it be a command line flag, or we would just leave out the option entirely. Perhaps I'd be less unhappy about this change if the flag were off in layout tests, so that we didn't have to change them all to remove alert() in unload. That patch was scrapped. Now alerts during unload handlers will just log to the console, so the alerts can be left in. The expected results for the tests will change a bit though since the message being logged is different. Right. In addition, the proposed patch only enables this for chromium, so other ports are not affected. Can I get a review? http://webkit.org/b/56397 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Unverified cert: Allow wss:// if user has accepted https:// warning? (WebKit Bug 41419)
Hi all, I originally sent this to webkit-help, but I probably should have posted it here instead. I'd like to request an alternate resolution to the following issue: https://bugs.webkit.org/show_bug.cgi?id=41419 We should log the reason when a secure wss WebSocket connection could not be established (was: Secure wss WebSocket connections cannot be established) Consider an example https://appliance.example.com, which uses a self-signed SSL certificate. iOS Safari will warn the user: Cannot Verify Server Identify Safari can't verify the identity of appliance.example.com. Would you like to continue anyway? Cancel / Details / Continue The user chooses to Continue. Safari then trusts the identity of appliance.example.com, and proceeds. The resulting HTML may spawn additional https:// requests, which will also proceed. Suppose though that a wss:// connection to appliance.example.com is initiated. As issue 41419 states, this will fail in Safari and WebKit (r87480.) Chrome on the other hand, consider the user's acceptance of the server's identity as valid for both wss:// and https:// connection. This seems reasonable. The user accepted the server's identity, with no caveat on the protocol. Can this behaviour be implemented in WebKit as the resolution to issue 41419? -Paul paulmoss...@avaya.com ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] [Webkit GTK][Windows] Plug-ins fails to load
On Mon, Jun 27, 2011 at 9:42 PM, dipak kumar mail.di...@gmail.com wrote: I have configured Webkit GTK port on Win32. Apart from that I have created some NPAPI architecture based plug-in to implement my own functionality. I have created DLL's and keeping them on the standard MOZ_PLUGIN_PATH path. But my GTKLauncher application is unable to load these plug-ins. What I am doing wrong? I couldn't find anything on net apart from a bug ( https://bugs.webkit.org/show_bug.cgi?id=54531 ). Could anybody please confirm whether it is possible to load plug-in on windows or not. As the bug says, I don't think it works at the moment. We'd appreciate someone with a stake in plugins working on Windows to fix this. I believe it should not be *too* difficult, but right now people using WebKitGTK+ on Windows are very few. --Martin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Adding ENABLE_CONTACTS to WebCore
On Jun 27, 2011, at 9:49 AM, Ojan Vafai wrote: Can you give an example of a smooth UI that you'd need the more complex API for? When I think of the existing mail and chat apps in iOS/Android that I've use, input type=contacts could give just as smooth a UI as the existing apps, it's just on the browser side to make the UI good instead of on the web developer side. I think a token field based UI for this (like the address field in Mail on Mac OS X, or the attendees field in iCal) might make for good UI for this sort of thing. But this design assumes that the email address is desired, or at least relevant to display. Are there use cases where a contact is desired for a purpose completely unrelated to email addresses? Perhaps if you are making a dialer or an SMS app, but I'm not sure that is a case we want to support. Regards, Maciej Ojan On Mon, Jun 27, 2011 at 3:37 AM, Alex Nicolaou anico...@google.com wrote: A user agent defined solution will make apps like mail, chat, Facebook, and so on all feel awful in safari versus installing a native app. It's like j2me all over again unless the website can provide a smooth ui. Alex On Friday, June 24, 2011, Ojan Vafai o...@chromium.org wrote: Is there a document that lists the use-cases for this API? I couldn't find anything from a quick glance through the DAP working group's mailing list archive. A list of use-cases would help evaluate whether this is the best API. At first glance, it strikes me that something like input type=contacts would meet the uses-cases I can think of better. Ojan On Thu, Jun 23, 2011 at 11:28 PM, 김동관 donggwan@samsung.com wrote: Hi webkit-dev! I wanted to let you know that I plan to add Contacts API support to WebKit. This API is a new feature that is published by W3C. The Device APIs Working Group of W3C has just released a Last Call Working Draft of its Contacts API: http://www.w3.org/TR/2011/WD-contacts-api-20110616/ I'm going to commit patch for Contacts API implementation very soon. This support will be behind the ENABLE_CONTACTS feature define. See: https://bugs.webkit.org/show_bug.cgi?id=63223 We'll be setting up a buildbot to track then ENABLE_CONTACTS build shortly. We expect this feature to be eventually enabled by all ports. Looking forward to your comments. Thank you. Donggwan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev -- -- Try Gmail Offline for Chrome http://goto.ext.google.com/fastgmail-chrome, and send me your complaints! ___ 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] Unverified cert: Allow wss:// if user has accepted https:// warning? (WebKit Bug 41419)
This isn't a WebKit issue. It's an issue for the embedding application. You'll need to file a bug with the relevant browser vendor. For Apple, you can use https://bugreport.apple.com/ or Chromium, you can use http://new.crbug.com/ Good luck! Adam On Tue, Jun 28, 2011 at 8:39 AM, Mossman, Paul (Paul) paulmoss...@avaya.com wrote: Hi all, I originally sent this to webkit-help, but I probably should have posted it here instead. I'd like to request an alternate resolution to the following issue: https://bugs.webkit.org/show_bug.cgi?id=41419 We should log the reason when a secure wss WebSocket connection could not be established (was: Secure wss WebSocket connections cannot be established) Consider an example https://appliance.example.com, which uses a self-signed SSL certificate. iOS Safari will warn the user: Cannot Verify Server Identify Safari can't verify the identity of appliance.example.com. Would you like to continue anyway? Cancel / Details / Continue The user chooses to Continue. Safari then trusts the identity of appliance.example.com, and proceeds. The resulting HTML may spawn additional https:// requests, which will also proceed. Suppose though that a wss:// connection to appliance.example.com is initiated. As issue 41419 states, this will fail in Safari and WebKit (r87480.) Chrome on the other hand, consider the user's acceptance of the server's identity as valid for both wss:// and https:// connection. This seems reasonable. The user accepted the server's identity, with no caveat on the protocol. Can this behaviour be implemented in WebKit as the resolution to issue 41419? -Paul paulmoss...@avaya.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
Re: [webkit-dev] Adding ENABLE_CONTACTS to WebCore
On Tue, Jun 28, 2011 at 10:10 AM, Maciej Stachowiak m...@apple.com wrote: On Jun 27, 2011, at 9:49 AM, Ojan Vafai wrote: Can you give an example of a smooth UI that you'd need the more complex API for? When I think of the existing mail and chat apps in iOS/Android that I've use, input type=contacts could give just as smooth a UI as the existing apps, it's just on the browser side to make the UI good instead of on the web developer side. I think a token field based UI for this (like the address field in Mail on Mac OS X, or the attendees field in iCal) might make for good UI for this sort of thing. But this design assumes that the email address is desired, or at least relevant to display. Are there use cases where a contact is desired for a purpose completely unrelated to email addresses? Perhaps if you are making a dialer or an SMS app, but I'm not sure that is a case we want to support. I think we probably do want to support those use-cases. You could still make this work with an input element. Security-wise, I think it would be OK to expose the entirety of the contact info once the user selects a contact. So the app would then be able to show whatever they want in the UI. I didn't want to delve too much into API details before getting a list of use-cases, but with the use-cases I have in mind, I think we'd also want a way of filtering items the user can pick from, similar to the accept attribute on input type=file. For example, for an SMS app we'd only want to show contacts that have a mobile phone number. Ojan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Shadow DOM API (first iteration) ready for landing
Dear WebKit, After nearly a year of building up the shadow DOM plumbing and converting WebKit to use it, we are finally at the point where we can expose this plumbing as public-facing API. The approach we take here is a very cautious one: we want to expose the minimum subset of the larger Web Component Model (some of you might remember is it as XBL2). The goal is to minimize the impact, but have something useful enough for Web developers to help us gather feedback. After careful consideration, we've come up with this subset for our first iteration: http://dglazkov.github.com/component-model/dom.html Since this is an experimental API, here are the actual API names we want to use: Element.webkitShadow Element.webkitPseudo document.webkitCreateShadow() window.WebKitShadowRootConstructor window.WebKitTreeScopeConstructor We will also provide the ENABLE(COMPONENT_MODEL) flag to control availability of this API and its iterations, even though all of the C++ code will always compile, since it's used throughout WebKit. NOTE: This iteration of the API is not intended to ship in a release version of a browser (think nightlies and dev channel only). Be sure to disable it on your respective release branches. Please chime in if you have concerns. Wish us luck! :DG ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Shadow DOM API (first iteration) ready for landing
Hi Dmitri. Since this is an experimental API, here are the actual API names we want to use: Element.webkitShadow Element.webkitPseudo document.webkitCreateShadow() window.WebKitShadowRootConstructor window.WebKitTreeScopeConstructor Even though we've been using shadow as a term in our internal development, I think it makes a bad API name, since it's vague to its purpose, and it conflicts with the existing meaning of shadow on the web, which is a color radiating around a visual element. Perhaps component or subtree or disconnectedTree would be a better API name. Geoff ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Switching away from integers for layout
On Fri, Jun 24, 2011 at 7:11 AM, Levi Weintraub le...@google.com wrote: Emil and I looked into what Firefox did. They did go with a fixed-point-esque approach where one of their units represents 1/96th of a pixel. That number should tell you something about when this work was done, and they were mostly concerned about performance. Back in the mists of time the units were variable and sometimes equal to 1/96 of a pixel. More recently (but still years ago) we changed to 1/60 of a CSS pixel. And we chose fixed-point-esque not just because of performance but also because you keep useful properties such as associativity and commutativity. If you're doing performance tests, make sure you test on ARM systems, which have widely varying floating-point capabilities. Rob -- If we claim to be without sin, we deceive ourselves and the truth is not in us. If we confess our sins, he is faithful and just and will forgive us our sins and purify us from all unrighteousness. If we claim we have not sinned, we make him out to be a liar and his word is not in us. [1 John 1:8-10] ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Writing a new XML parser with no external libraries
Currently, WebCore uses libxml2, or, if available, QtXml to parse incoming XML. However, QtXml isn't always available, and using libxml2 exposes its own share of problems. As such, I'm undertaking writing an XML parser that uses no external libraries. The first step to doing this is to add a new flag that switches off the other two parsers. As the parsers are already independent and can be switched between by checking USE(QXMLSTREAM), I am adding USE(LIBXML2) checks, replacing the #else conditionals, and also a new ENABLE check, tentatively called NEW_XML (although names such as NATIVE_XML or XML_NATIVE, etc, may be more appropriate). As there will probably be a new slew of files pertaining to XML parsing, I will put these files in WebCore/xml/parser, and move the existing XMLDocumentParser* file into this new directory. As far as I know, the placement of these files in WebCore/dom/ is legacy, and, assuming the build on each platform is changed, it makes sense to move them. Once all the files are in a logical place, I plan to make a new file for a skeleton of the new XMLDocumentParser, at least to get it to link until a real one is in place, even if the XML parser at that point is just a data sink. From there, I plan to copy and modify a good chunk of the lower level HTML tokenization and parsing code, and make changes as necessary to make it work on generalized XML, at least until I can generalize the common code in such a way that the HTML and XML tokenizers can be subclasses and use common code. I'd probably do the refactoring at the end. I'm still exploring the existing parsing code, but I'd probably work my way up from there. I've read a lot of the XML 1.0 spec in preparation, as well, but it doesn't have much on implementation itself. If QtWebKit or parsing people have any comments, concerns, or help, I'd be more than willing to listen--I'm just starting here, and I'm not completely familiar with the codebase. Although no code is checked in so far, I've started on this list already and have gotten as far as the new flags, a skeleton XMLDocumentParserNew.cpp, and making a tokenizer that compiles and links, but is completely untested. Jeffrey Pfau ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Writing a new XML parser with no external libraries
A question and a comment: 1) Will this let us to remove the code for both the libxml2 and the QtXml parsers? I'd certainly much rather have one XML parser than three. 2) One thing we found very helpful in working on the HTML parser was a good test suite. Presumably there are existing XML parsing test suites. You might consider landing one (or more) of these test suites as a first step. Adam On Tue, Jun 28, 2011 at 6:12 PM, Jeffrey Pfau jp...@apple.com wrote: Currently, WebCore uses libxml2, or, if available, QtXml to parse incoming XML. However, QtXml isn't always available, and using libxml2 exposes its own share of problems. As such, I'm undertaking writing an XML parser that uses no external libraries. The first step to doing this is to add a new flag that switches off the other two parsers. As the parsers are already independent and can be switched between by checking USE(QXMLSTREAM), I am adding USE(LIBXML2) checks, replacing the #else conditionals, and also a new ENABLE check, tentatively called NEW_XML (although names such as NATIVE_XML or XML_NATIVE, etc, may be more appropriate). As there will probably be a new slew of files pertaining to XML parsing, I will put these files in WebCore/xml/parser, and move the existing XMLDocumentParser* file into this new directory. As far as I know, the placement of these files in WebCore/dom/ is legacy, and, assuming the build on each platform is changed, it makes sense to move them. Once all the files are in a logical place, I plan to make a new file for a skeleton of the new XMLDocumentParser, at least to get it to link until a real one is in place, even if the XML parser at that point is just a data sink. From there, I plan to copy and modify a good chunk of the lower level HTML tokenization and parsing code, and make changes as necessary to make it work on generalized XML, at least until I can generalize the common code in such a way that the HTML and XML tokenizers can be subclasses and use common code. I'd probably do the refactoring at the end. I'm still exploring the existing parsing code, but I'd probably work my way up from there. I've read a lot of the XML 1.0 spec in preparation, as well, but it doesn't have much on implementation itself. If QtWebKit or parsing people have any comments, concerns, or help, I'd be more than willing to listen--I'm just starting here, and I'm not completely familiar with the codebase. Although no code is checked in so far, I've started on this list already and have gotten as far as the new flags, a skeleton XMLDocumentParserNew.cpp, and making a tokenizer that compiles and links, but is completely untested. Jeffrey Pfau ___ 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] Writing a new XML parser with no external libraries
Can you expand a bit more on using libxml2 exposes its own share of problems? -- Dirk On Tue, Jun 28, 2011 at 6:12 PM, Jeffrey Pfau jp...@apple.com wrote: Currently, WebCore uses libxml2, or, if available, QtXml to parse incoming XML. However, QtXml isn't always available, and using libxml2 exposes its own share of problems. As such, I'm undertaking writing an XML parser that uses no external libraries. The first step to doing this is to add a new flag that switches off the other two parsers. As the parsers are already independent and can be switched between by checking USE(QXMLSTREAM), I am adding USE(LIBXML2) checks, replacing the #else conditionals, and also a new ENABLE check, tentatively called NEW_XML (although names such as NATIVE_XML or XML_NATIVE, etc, may be more appropriate). As there will probably be a new slew of files pertaining to XML parsing, I will put these files in WebCore/xml/parser, and move the existing XMLDocumentParser* file into this new directory. As far as I know, the placement of these files in WebCore/dom/ is legacy, and, assuming the build on each platform is changed, it makes sense to move them. Once all the files are in a logical place, I plan to make a new file for a skeleton of the new XMLDocumentParser, at least to get it to link until a real one is in place, even if the XML parser at that point is just a data sink. From there, I plan to copy and modify a good chunk of the lower level HTML tokenization and parsing code, and make changes as necessary to make it work on generalized XML, at least until I can generalize the common code in such a way that the HTML and XML tokenizers can be subclasses and use common code. I'd probably do the refactoring at the end. I'm still exploring the existing parsing code, but I'd probably work my way up from there. I've read a lot of the XML 1.0 spec in preparation, as well, but it doesn't have much on implementation itself. If QtWebKit or parsing people have any comments, concerns, or help, I'd be more than willing to listen--I'm just starting here, and I'm not completely familiar with the codebase. Although no code is checked in so far, I've started on this list already and have gotten as far as the new flags, a skeleton XMLDocumentParserNew.cpp, and making a tokenizer that compiles and links, but is completely untested. Jeffrey Pfau ___ 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] Writing a new XML parser with no external libraries
I don't know all of the problems libxml2 has, but one of the ones I've heard is that WebCore uses UTF-16 internally, and libxml2 uses UTF-8, so the data is perpetually converted between the two formats--and this is slow. If there are any other big ones, I haven't been told them, only that it would be good to have a replacement. Jeffrey Pfau On Jun 28, 2011, at 6:30 PM, Dirk Pranke wrote: Can you expand a bit more on using libxml2 exposes its own share of problems? -- Dirk On Tue, Jun 28, 2011 at 6:12 PM, Jeffrey Pfau jp...@apple.com wrote: Currently, WebCore uses libxml2, or, if available, QtXml to parse incoming XML. However, QtXml isn't always available, and using libxml2 exposes its own share of problems. As such, I'm undertaking writing an XML parser that uses no external libraries. The first step to doing this is to add a new flag that switches off the other two parsers. As the parsers are already independent and can be switched between by checking USE(QXMLSTREAM), I am adding USE(LIBXML2) checks, replacing the #else conditionals, and also a new ENABLE check, tentatively called NEW_XML (although names such as NATIVE_XML or XML_NATIVE, etc, may be more appropriate). As there will probably be a new slew of files pertaining to XML parsing, I will put these files in WebCore/xml/parser, and move the existing XMLDocumentParser* file into this new directory. As far as I know, the placement of these files in WebCore/dom/ is legacy, and, assuming the build on each platform is changed, it makes sense to move them. Once all the files are in a logical place, I plan to make a new file for a skeleton of the new XMLDocumentParser, at least to get it to link until a real one is in place, even if the XML parser at that point is just a data sink. From there, I plan to copy and modify a good chunk of the lower level HTML tokenization and parsing code, and make changes as necessary to make it work on generalized XML, at least until I can generalize the common code in such a way that the HTML and XML tokenizers can be subclasses and use common code. I'd probably do the refactoring at the end. I'm still exploring the existing parsing code, but I'd probably work my way up from there. I've read a lot of the XML 1.0 spec in preparation, as well, but it doesn't have much on implementation itself. If QtWebKit or parsing people have any comments, concerns, or help, I'd be more than willing to listen--I'm just starting here, and I'm not completely familiar with the codebase. Although no code is checked in so far, I've started on this list already and have gotten as far as the new flags, a skeleton XMLDocumentParserNew.cpp, and making a tokenizer that compiles and links, but is completely untested. Jeffrey Pfau ___ 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] Writing a new XML parser with no external libraries
See responses inline: On Jun 28, 2011, at 6:26 PM, Adam Barth wrote: A question and a comment: 1) Will this let us to remove the code for both the libxml2 and the QtXml parsers? I'd certainly much rather have one XML parser than three. This won't replace libxslt or QtXmlPatterns for XSL-T, as they depend on the respective XML libraries. The goal for this XML parser is to be able to replace the core XML parser itself. XSL-T support would have to come later. 2) One thing we found very helpful in working on the HTML parser was a good test suite. Presumably there are existing XML parsing test suites. You might consider landing one (or more) of these test suites as a first step. Adam I know that W3C provides a test suite, but it's probably not that comprehensive. I can try to find more online; I'm sure that some of the open source projects like libxml2 provide some. Jeffrey Pfau On Tue, Jun 28, 2011 at 6:12 PM, Jeffrey Pfau jp...@apple.com wrote: Currently, WebCore uses libxml2, or, if available, QtXml to parse incoming XML. However, QtXml isn't always available, and using libxml2 exposes its own share of problems. As such, I'm undertaking writing an XML parser that uses no external libraries. The first step to doing this is to add a new flag that switches off the other two parsers. As the parsers are already independent and can be switched between by checking USE(QXMLSTREAM), I am adding USE(LIBXML2) checks, replacing the #else conditionals, and also a new ENABLE check, tentatively called NEW_XML (although names such as NATIVE_XML or XML_NATIVE, etc, may be more appropriate). As there will probably be a new slew of files pertaining to XML parsing, I will put these files in WebCore/xml/parser, and move the existing XMLDocumentParser* file into this new directory. As far as I know, the placement of these files in WebCore/dom/ is legacy, and, assuming the build on each platform is changed, it makes sense to move them. Once all the files are in a logical place, I plan to make a new file for a skeleton of the new XMLDocumentParser, at least to get it to link until a real one is in place, even if the XML parser at that point is just a data sink. From there, I plan to copy and modify a good chunk of the lower level HTML tokenization and parsing code, and make changes as necessary to make it work on generalized XML, at least until I can generalize the common code in such a way that the HTML and XML tokenizers can be subclasses and use common code. I'd probably do the refactoring at the end. I'm still exploring the existing parsing code, but I'd probably work my way up from there. I've read a lot of the XML 1.0 spec in preparation, as well, but it doesn't have much on implementation itself. If QtWebKit or parsing people have any comments, concerns, or help, I'd be more than willing to listen--I'm just starting here, and I'm not completely familiar with the codebase. Although no code is checked in so far, I've started on this list already and have gotten as far as the new flags, a skeleton XMLDocumentParserNew.cpp, and making a tokenizer that compiles and links, but is completely untested. Jeffrey Pfau ___ 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] Writing a new XML parser with no external libraries
If that were all, would it be possible to patch libxml2 to use UTF-16? That might be less of an undertaking than writing a new xml library, but that could just be my youthful naivety.. On Tue, Jun 28, 2011 at 6:36 PM, Jeffrey Pfau jp...@apple.com wrote: I don't know all of the problems libxml2 has, but one of the ones I've heard is that WebCore uses UTF-16 internally, and libxml2 uses UTF-8, so the data is perpetually converted between the two formats--and this is slow. If there are any other big ones, I haven't been told them, only that it would be good to have a replacement. Jeffrey Pfau On Jun 28, 2011, at 6:30 PM, Dirk Pranke wrote: Can you expand a bit more on using libxml2 exposes its own share of problems? -- Dirk On Tue, Jun 28, 2011 at 6:12 PM, Jeffrey Pfau jp...@apple.com wrote: Currently, WebCore uses libxml2, or, if available, QtXml to parse incoming XML. However, QtXml isn't always available, and using libxml2 exposes its own share of problems. As such, I'm undertaking writing an XML parser that uses no external libraries. The first step to doing this is to add a new flag that switches off the other two parsers. As the parsers are already independent and can be switched between by checking USE(QXMLSTREAM), I am adding USE(LIBXML2) checks, replacing the #else conditionals, and also a new ENABLE check, tentatively called NEW_XML (although names such as NATIVE_XML or XML_NATIVE, etc, may be more appropriate). As there will probably be a new slew of files pertaining to XML parsing, I will put these files in WebCore/xml/parser, and move the existing XMLDocumentParser* file into this new directory. As far as I know, the placement of these files in WebCore/dom/ is legacy, and, assuming the build on each platform is changed, it makes sense to move them. Once all the files are in a logical place, I plan to make a new file for a skeleton of the new XMLDocumentParser, at least to get it to link until a real one is in place, even if the XML parser at that point is just a data sink. From there, I plan to copy and modify a good chunk of the lower level HTML tokenization and parsing code, and make changes as necessary to make it work on generalized XML, at least until I can generalize the common code in such a way that the HTML and XML tokenizers can be subclasses and use common code. I'd probably do the refactoring at the end. I'm still exploring the existing parsing code, but I'd probably work my way up from there. I've read a lot of the XML 1.0 spec in preparation, as well, but it doesn't have much on implementation itself. If QtWebKit or parsing people have any comments, concerns, or help, I'd be more than willing to listen--I'm just starting here, and I'm not completely familiar with the codebase. Although no code is checked in so far, I've started on this list already and have gotten as far as the new flags, a skeleton XMLDocumentParserNew.cpp, and making a tokenizer that compiles and links, but is completely untested. Jeffrey Pfau ___ 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] Writing a new XML parser with no external libraries
Correct. We convert from UTF16 to UTF8 (for libxml2) and then back to UTF16. There has been at least one libxml-related security fix to WebCore in recent memory. We have various hacks in the libxml2 parser due to libxml2 being designed to be a library used by applications, and not used by a library like WebKit: http://trac.webkit.org/browser/trunk/Source/WebCore/dom/XMLDocumentParserLibxml2.cpp#L373 http://trac.webkit.org/browser/trunk/Source/WebCore/dom/XMLDocumentParserLibxml2.cpp#L488 http://trac.webkit.org/browser/trunk/Source/WebCore/dom/XMLDocumentParserLibxml2.cpp#L1093 http://trac.webkit.org/browser/trunk/Source/WebCore/dom/XMLDocumentParserLibxml2.cpp#L1182 http://trac.webkit.org/browser/trunk/Source/WebCore/dom/XMLDocumentParserLibxml2.cpp#L1273 I'm in general in favor of this effort (having worked extensively on the existing XML parsers). But I would caution you that xml is a ridiculously tiny fraction of the web. And it may not be worth the engineering effort to make a better parser. http://www.google.com/search?q=filetype:html = 25,270,000,000 http://www.google.com/search?q=filetype:xml = 71,000,000 (Naively) judging by those numbers we should be spending 356 times as much effort on our HTML support than our XML support. :) -eric -eric On Tue, Jun 28, 2011 at 6:36 PM, Jeffrey Pfau jp...@apple.com wrote: I don't know all of the problems libxml2 has, but one of the ones I've heard is that WebCore uses UTF-16 internally, and libxml2 uses UTF-8, so the data is perpetually converted between the two formats--and this is slow. If there are any other big ones, I haven't been told them, only that it would be good to have a replacement. Jeffrey Pfau On Jun 28, 2011, at 6:30 PM, Dirk Pranke wrote: Can you expand a bit more on using libxml2 exposes its own share of problems? -- Dirk On Tue, Jun 28, 2011 at 6:12 PM, Jeffrey Pfau jp...@apple.com wrote: Currently, WebCore uses libxml2, or, if available, QtXml to parse incoming XML. However, QtXml isn't always available, and using libxml2 exposes its own share of problems. As such, I'm undertaking writing an XML parser that uses no external libraries. The first step to doing this is to add a new flag that switches off the other two parsers. As the parsers are already independent and can be switched between by checking USE(QXMLSTREAM), I am adding USE(LIBXML2) checks, replacing the #else conditionals, and also a new ENABLE check, tentatively called NEW_XML (although names such as NATIVE_XML or XML_NATIVE, etc, may be more appropriate). As there will probably be a new slew of files pertaining to XML parsing, I will put these files in WebCore/xml/parser, and move the existing XMLDocumentParser* file into this new directory. As far as I know, the placement of these files in WebCore/dom/ is legacy, and, assuming the build on each platform is changed, it makes sense to move them. Once all the files are in a logical place, I plan to make a new file for a skeleton of the new XMLDocumentParser, at least to get it to link until a real one is in place, even if the XML parser at that point is just a data sink. From there, I plan to copy and modify a good chunk of the lower level HTML tokenization and parsing code, and make changes as necessary to make it work on generalized XML, at least until I can generalize the common code in such a way that the HTML and XML tokenizers can be subclasses and use common code. I'd probably do the refactoring at the end. I'm still exploring the existing parsing code, but I'd probably work my way up from there. I've read a lot of the XML 1.0 spec in preparation, as well, but it doesn't have much on implementation itself. If QtWebKit or parsing people have any comments, concerns, or help, I'd be more than willing to listen--I'm just starting here, and I'm not completely familiar with the codebase. Although no code is checked in so far, I've started on this list already and have gotten as far as the new flags, a skeleton XMLDocumentParserNew.cpp, and making a tokenizer that compiles and links, but is completely untested. Jeffrey Pfau ___ 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] Writing a new XML parser with no external libraries
That was done, long ago. You can find the old patches in our svn history. :) On Tue, Jun 28, 2011 at 6:44 PM, Wyatt Carss wca...@google.com wrote: If that were all, would it be possible to patch libxml2 to use UTF-16? That might be less of an undertaking than writing a new xml library, but that could just be my youthful naivety.. On Tue, Jun 28, 2011 at 6:36 PM, Jeffrey Pfau jp...@apple.com wrote: I don't know all of the problems libxml2 has, but one of the ones I've heard is that WebCore uses UTF-16 internally, and libxml2 uses UTF-8, so the data is perpetually converted between the two formats--and this is slow. If there are any other big ones, I haven't been told them, only that it would be good to have a replacement. Jeffrey Pfau On Jun 28, 2011, at 6:30 PM, Dirk Pranke wrote: Can you expand a bit more on using libxml2 exposes its own share of problems? -- Dirk On Tue, Jun 28, 2011 at 6:12 PM, Jeffrey Pfau jp...@apple.com wrote: Currently, WebCore uses libxml2, or, if available, QtXml to parse incoming XML. However, QtXml isn't always available, and using libxml2 exposes its own share of problems. As such, I'm undertaking writing an XML parser that uses no external libraries. The first step to doing this is to add a new flag that switches off the other two parsers. As the parsers are already independent and can be switched between by checking USE(QXMLSTREAM), I am adding USE(LIBXML2) checks, replacing the #else conditionals, and also a new ENABLE check, tentatively called NEW_XML (although names such as NATIVE_XML or XML_NATIVE, etc, may be more appropriate). As there will probably be a new slew of files pertaining to XML parsing, I will put these files in WebCore/xml/parser, and move the existing XMLDocumentParser* file into this new directory. As far as I know, the placement of these files in WebCore/dom/ is legacy, and, assuming the build on each platform is changed, it makes sense to move them. Once all the files are in a logical place, I plan to make a new file for a skeleton of the new XMLDocumentParser, at least to get it to link until a real one is in place, even if the XML parser at that point is just a data sink. From there, I plan to copy and modify a good chunk of the lower level HTML tokenization and parsing code, and make changes as necessary to make it work on generalized XML, at least until I can generalize the common code in such a way that the HTML and XML tokenizers can be subclasses and use common code. I'd probably do the refactoring at the end. I'm still exploring the existing parsing code, but I'd probably work my way up from there. I've read a lot of the XML 1.0 spec in preparation, as well, but it doesn't have much on implementation itself. If QtWebKit or parsing people have any comments, concerns, or help, I'd be more than willing to listen--I'm just starting here, and I'm not completely familiar with the codebase. Although no code is checked in so far, I've started on this list already and have gotten as far as the new flags, a skeleton XMLDocumentParserNew.cpp, and making a tokenizer that compiles and links, but is completely untested. Jeffrey Pfau ___ 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] Writing a new XML parser with no external libraries
In case you're not aware, I believe you can access the XML parser via JavaScript at window.DOMParser, which might be helpful for testing. Adam On Jun 28, 2011 6:41 PM, Jeffrey Pfau jp...@apple.com wrote: See responses inline: On Jun 28, 2011, at 6:26 PM, Adam Barth wrote: A question and a comment: 1) Will this let us to remove the code for both the libxml2 and the QtXml parsers? I'd certainly much rather have one XML parser than three. This won't replace libxslt or QtXmlPatterns for XSL-T, as they depend on the respective XML libraries. The goal for this XML parser is to be able to replace the core XML parser itself. XSL-T support would have to come later. 2) One thing we found very helpful in working on the HTML parser was a good test suite. Presumably there are existing XML parsing test suites. You might consider landing one (or more) of these test suites as a first step. Adam I know that W3C provides a test suite, but it's probably not that comprehensive. I can try to find more online; I'm sure that some of the open source projects like libxml2 provide some. Jeffrey Pfau On Tue, Jun 28, 2011 at 6:12 PM, Jeffrey Pfau jp...@apple.com wrote: Currently, WebCore uses libxml2, or, if available, QtXml to parse incoming XML. However, QtXml isn't always available, and using libxml2 exposes its own share of problems. As such, I'm undertaking writing an XML parser that uses no external libraries. The first step to doing this is to add a new flag that switches off the other two parsers. As the parsers are already independent and can be switched between by checking USE(QXMLSTREAM), I am adding USE(LIBXML2) checks, replacing the #else conditionals, and also a new ENABLE check, tentatively called NEW_XML (although names such as NATIVE_XML or XML_NATIVE, etc, may be more appropriate). As there will probably be a new slew of files pertaining to XML parsing, I will put these files in WebCore/xml/parser, and move the existing XMLDocumentParser* file into this new directory. As far as I know, the placement of these files in WebCore/dom/ is legacy, and, assuming the build on each platform is changed, it makes sense to move them. Once all the files are in a logical place, I plan to make a new file for a skeleton of the new XMLDocumentParser, at least to get it to link until a real one is in place, even if the XML parser at that point is just a data sink. From there, I plan to copy and modify a good chunk of the lower level HTML tokenization and parsing code, and make changes as necessary to make it work on generalized XML, at least until I can generalize the common code in such a way that the HTML and XML tokenizers can be subclasses and use common code. I'd probably do the refactoring at the end. I'm still exploring the existing parsing code, but I'd probably work my way up from there. I've read a lot of the XML 1.0 spec in preparation, as well, but it doesn't have much on implementation itself. If QtWebKit or parsing people have any comments, concerns, or help, I'd be more than willing to listen--I'm just starting here, and I'm not completely familiar with the codebase. Although no code is checked in so far, I've started on this list already and have gotten as far as the new flags, a skeleton XMLDocumentParserNew.cpp, and making a tokenizer that compiles and links, but is completely untested. Jeffrey Pfau ___ 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] Writing a new XML parser with no external libraries
Consolidating replies to avoid spamming the thread: On Jun 28, 2011, at 6:26 PM, Adam Barth wrote: A question and a comment: 1) Will this let us to remove the code for both the libxml2 and the QtXml parsers? I'd certainly much rather have one XML parser than three. If the new parser pans out, I think it would be up to individual ports to decide when/whether to migrate to it. I hope it can obsolete at least the libxml2 parser, though it won't by itself eliminate the need to link libxml2 due to XSLT. If it doesn't pan out, then presumably we won't leave dead code in the tree. On Jun 28, 2011, at 6:44 PM, Wyatt Carss wrote: If that were all, would it be possible to patch libxml2 to use UTF-16? That might be less of an undertaking than writing a new xml library, but that could just be my youthful naivety.. Maintaining such a patch set in the face of upstream libxml2 security fixes would probably be challenging. Enough so that investing some up-front effort to make our own parser may be a better solution. On Jun 28, 2011, at 6:30 PM, Dirk Pranke wrote: Can you expand a bit more on using libxml2 exposes its own share of problems? Besides the charset conversion performance issue mentioned by Jeffrey, and the need for hacks mentioned by Eric, here are some others: - Our code to glue libxml2 to WebCore is a surprisingly frequent source of crashers and security bugs. - libxml2 has security bugs reasonably often, and creates the need for an extra upstream update to pull those fixes. - Improving performance or security of libxml2 in a systematic way, or adding features, has relatively high barriers to entry for WebKit developers. - libxml2 is yet another dependency and it would be nice to have fewer - while this project won't eliminate the need entirely, it is one required step - libxml2 contains a bunch of stuff we don't need, like its own HTML4 parser, XPointer, XInclude, XML Schemas, RelaxNG, XML Catalogs… On Jun 28, 2011, at 6:50 PM, Eric Seidel wrote: I'm in general in favor of this effort (having worked extensively on the existing XML parsers). But I would caution you that xml is a ridiculously tiny fraction of the web. And it may not be worth the engineering effort to make a better parser. The XML parser has uses besides what is obvious from files named .xml on the Web. It is used on some notable Web expert websites, for non-inline SVG images (which can be found on Wikipedia, a rather popular site), for processing the results of XML returned to XMLHttpRequest, and for processing non-Web content using the Web engine, such as ePub books. So it punches above its weight in a number of ways. Also, security bugs don't care how popular or unpopular a format is. Also, based on your methodology, one would conclude we should spend 5 times as much effort on XML as PNG, which while less than effort spent on HTML is a good deal more than 0: http://www.google.com/search?q=filetype:png So I think it is worth some investment. Much like XBL2, this is one of those longstanding items that needs to rise to the top of someone's list. Additional note: a native XML parser was a fairly heavily discussed potential project at the WebKit contributors' meeting. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Writing a new XML parser with no external libraries
I'm a little negative of developing a new XML parser. I'm afraid that the new parser introduces a lot of security/stability problems which existing parsers already resolved. How about importing Expat parser to WebKit repository and maintain it by ourselves? On Wed, Jun 29, 2011 at 10:12, Jeffrey Pfau jp...@apple.com wrote: Currently, WebCore uses libxml2, or, if available, QtXml to parse incoming XML. However, QtXml isn't always available, and using libxml2 exposes its own share of problems. As such, I'm undertaking writing an XML parser that uses no external libraries. The first step to doing this is to add a new flag that switches off the other two parsers. As the parsers are already independent and can be switched between by checking USE(QXMLSTREAM), I am adding USE(LIBXML2) checks, replacing the #else conditionals, and also a new ENABLE check, tentatively called NEW_XML (although names such as NATIVE_XML or XML_NATIVE, etc, may be more appropriate). As there will probably be a new slew of files pertaining to XML parsing, I will put these files in WebCore/xml/parser, and move the existing XMLDocumentParser* file into this new directory. As far as I know, the placement of these files in WebCore/dom/ is legacy, and, assuming the build on each platform is changed, it makes sense to move them. Once all the files are in a logical place, I plan to make a new file for a skeleton of the new XMLDocumentParser, at least to get it to link until a real one is in place, even if the XML parser at that point is just a data sink. From there, I plan to copy and modify a good chunk of the lower level HTML tokenization and parsing code, and make changes as necessary to make it work on generalized XML, at least until I can generalize the common code in such a way that the HTML and XML tokenizers can be subclasses and use common code. I'd probably do the refactoring at the end. I'm still exploring the existing parsing code, but I'd probably work my way up from there. I've read a lot of the XML 1.0 spec in preparation, as well, but it doesn't have much on implementation itself. If QtWebKit or parsing people have any comments, concerns, or help, I'd be more than willing to listen--I'm just starting here, and I'm not completely familiar with the codebase. Although no code is checked in so far, I've started on this list already and have gotten as far as the new flags, a skeleton XMLDocumentParserNew.cpp, and making a tokenizer that compiles and links, but is completely untested. Jeffrey Pfau ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev -- TAMURA Kent Software Engineer, Google ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Shadow DOM API (first iteration) ready for landing
On Jun 28, 2011, at 5:15 PM, Dimitri Glazkov wrote: On Tue, Jun 28, 2011 at 4:49 PM, Geoffrey Garen gga...@apple.com wrote: Hi Dmitri. Since this is an experimental API, here are the actual API names we want to use: Element.webkitShadow Element.webkitPseudo document.webkitCreateShadow() window.WebKitShadowRootConstructor window.WebKitTreeScopeConstructor Even though we've been using shadow as a term in our internal development, I think it makes a bad API name, since it's vague to its purpose, and it conflicts with the existing meaning of shadow on the web, which is a color radiating around a visual element. I sympathize and agree that there's a naming collision, but I think the train has left the station on this one. Shadow tree and shadow content are terms that have been used pretty much universally to describe this construct, from XBL/XUL and XBL2 to SVG. I don't think we need to invent a new name for it. Fair enough. How about using shadow tree or shadow content consistently instead of just shadow? I can imagine webkitShadow meaning a lot of different things. webkitShadowTree or webkitShadowContent seems clearer. Element.webkitShadowTree Element.webkitPseudo // not sure what this is -- showing my ignorance document.webkitCreateShadowTree() window.WebKitShadowTreeConstructor // all trees begin at a root, right? window.WebKitShadowTreeScopeConstructor // assuming this can only be used inside the shadow tree Geoff ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Writing a new XML parser with no external libraries
Am 29.06.2011 um 05:42 schrieb TAMURA, Kent: I'm a little negative of developing a new XML parser. I'm afraid that the new parser introduces a lot of security/stability problems which existing parsers already resolved. I feel the same. Writing a new parser from scratch means introducing a lot of new security bugs, parsing errors and maybe bigger performance lost at the beginning. Speaking from the SVG side, we fail at least three tests on the W3C SVG Test Suite because of parsing bugs if libxml2 on MacOS. All of these bugs are fixed in later versions of libxml2. Updating libxml2 more often on MacOS would help a lot. With the new parser we won't loose support XSLT and XLink support? Dirk ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
