Re: [webkit-dev] how about nav-up, nav-right, nav-down, nav-left in CSS3-ui ?
Hi, Here is the latest draft of the standard: http://dev.w3.org/csswg/css3-ui/ It looks the spec is alive, even if the discussion is not so active. http://wiki.csswg.org/spec/css3-ui What we should do to add new feature is described here: http://www.webkit.org/coding/adding-features.html Actually filing a bug will be good first step. Regards, -- morrita On Wed, Aug 10, 2011 at 10:18 AM, Ra Kyounga kyounga...@gmail.com wrote: Hi, CSS developers. I'm wondering if anyone is trying to implement new css properties for directional focus navgation. (nav-up, nav-right, nav-down, nav-left) They are defined in CSS3-ui module. http://www.w3.org/TR/css3-ui/#nav-dir Although, CSS3-UI standards has not been updated for long time, if there is no one to be addressed, I'd like to start to implement this feature. I think we can re-use the function for a fragment link. How about my idea? or Is it better just to start implementation through bugs.webkit.org than e-mail communication? Warm Regards, Kyounga ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev -- morrita ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Adding ENABLE_FLEXBOX to WebCore
+1 for runtime configuration. Keeping code runnable is nice, and hard if it's disabled on many developers' working copies. We don't need to use traditional flag-holder like Settings class and can use simple global-ish variables instead, because We don't need to configure it per-Page basis. I personally prefer compilation ENABLE flag only for possible optional features, and most of CSS functionalities aren't that case. (This claim might be controversial though.) -- morrita On Thu, Jun 9, 2011 at 1:29 PM, Darin Fisher da...@chromium.org wrote: OK, but it is very nice to ship what you test (i.e., avoid the need to create a separate build of WebCore for testing). Continuous integration is also nice (i.e., no branches). Marrying those constraints leads to runtime enabling features. This is precisely the recipe Chromium uses to great avail for features exposed through JS. Why wouldn't we want the same for CSS features? -Darin On Wed, Jun 8, 2011 at 5:48 PM, Adam Barth aba...@webkit.org wrote: The difference between runtime and compile time enabling seems like a red herring. The issue is more which configurations to test where and to ship where, not how to do the configuring. Adam On Jun 8, 2011 5:25 PM, Darin Fisher da...@chromium.org wrote: Are you referring to the additional cost of maintaining different test expectations between the two configs? Agreed, that would suck. So, how painful would it be to add runtime enablement support for new CSS features? On Jun 8, 2011 5:16 PM, Dirk Pranke dpra...@chromium.org wrote: On Wed, Jun 8, 2011 at 5:13 PM, Darin Fisher da...@chromium.org wrote: On Wed, Jun 8, 2011 at 4:59 PM, James Robinson jam...@google.com wrote: On Wed, Jun 8, 2011 at 4:55 PM, Darin Fisher da...@chromium.org wrote: Oh, okay. Why do we have override_features.gypi then? We don't, Adam tried to remove it earlier this week and was foiled by some weird complex failure. We should get rid of it ASAP. OK ... I guess things have changed. Regardless, it seems like we could create a mechanism so that the result of build-webkit uses different ENABLE_ options than a stock Chromium build. There's a trivial way to switch b/w the two in the GYP files. There's danger in testing a different set of ENABLE_s than we ship unless we are really confident in understanding how the ENABLE_'d code interacts with the rest of the codebase. I'm not sure that is a big deal. The Chromium build bots at build.chromium.org run DRT built from a Chromium checkout. The build.webkit.org bots are intended to provide compile and DRT feedback for the Chromium port that is visible to the rest of the WebKit community. If the configs between build.webkit.org and build.chromium.org differ, maybe that is not so bad? Boy, that seems like a recipe for pain from my point of view. I'd be against this unless there was a *big* win for some reason. -- Dirk ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev -- morrita ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] progress/meter/input[type=range] orientation and implications in WebKit
Hi, On Sat, Mar 5, 2011 at 11:24 AM, Dimitri Glazkov dglaz...@chromium.org wrote: On Fri, Mar 4, 2011 at 12:16 PM, Ian Hickson i...@hixie.ch wrote: On Fri, 4 Mar 2011, Dimitri Glazkov wrote: Today, we happily use -webkit-appearance to apply platform-specific appearance to the controls. The trouble is, the value of -webkit-appearance is going to be different depending on the value of logical width. Why not have a value of 'appearance' that automatically uses the right orientation, instead of having orientation-specific values? You are correct, the theme can paint correctly oriented slider controls in by looking at the box size it's painting. Hyatt pointed out the same thing on #webkit. However, the issue still exists in the cases of meter and progress. They are using plain-old CSS gradient rules, not magic platform painter (calked RenderTheme in WebKit). It's true. I'll add a context here. For Mac, which has native meter (indicator) components, WebKit uses platform painter. But for platforms other than mac, WebKit use two gradient-filled divs (one for the bar and another for background) to render the meter, because such platforms don't have own native indicators. Another idea to select the direction explicitly is to refer writing-mode or box-orient CSS property. I'm not sure whether this is a good idea though. Regards. -- morrita :DG ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Trouble with updating Chromium' slayout test expectations
Hi Chromium WebKit folks, I'm looking for a help to retrieve the latest expectation files for Chromium Mac LayoutTest. At the weekend there was a change that triggers massive amount of pixel test failures that requires rebaselining. (https://bugs.webkit.org/b/54736) But the buildbot doesn't have the latest result for part of them, that means * rebaseline-chromium-webkit-tests doesn't update pixel results * [layout test results] links on buildbot dashboard are broken. Then now around 100 tests for Mac Chromium are left marked as failed (BUGWK54736 lines), waiting for their fresh expectations. Unfortunately I have no idea what's happening but missing 100 tests will possibly hurt us. How could I update these expectations? Any suggestions and/or helps are appreciated. Regards. -- morrita ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Hunspell based spellchecker
Fabrizio, Ryan, thank you for your interest! Although I'm suspending the work at this time, your interest gives me a good reason to restart ;-) I'll CC you in bug(s) and post some status there within weeks. Regards. morrita On Thu, Jan 27, 2011 at 4:23 AM, Ryan Leavengood leaveng...@gmail.com wrote: On Wed, Jan 26, 2011 at 1:52 PM, Fabrizio Machado fabrizio.machado...@gmail.com wrote: This would rely on a spelling engine but, as qt has no spell checker, Hunspell integration to WebCore seems appealing. I was headed in this direction when I found this thread and I wonder if you are still pursuing this. Can you tell me if it is a worthwhile pursuit, or if you had problems? I'm interested in continuing, but give me a heads up if you were blocked for some reason. For what it is worth, the approach outlined by Hajime would also be useful for the Haiku port I am working on. I was already considering porting Hunspell to Haiku and making use of it in the Haiku port, but if multiple ports could benefit all the better. It seems like the TextCheckerClient approach is reasonable if it is architected in the same way as EditorClient and friends. The Hunspell based TextChecker could live in WebCore and link with Hunspell and would only be compiled and used by ports which need it. There would still need to be a TextCheckerClient in WebCoreSupport in WebKit to call to the TextCheckerHunspell or whatever in WebCore. Maybe this still isn't the right architecture but I don't think it is impossible to implement this in a way which matches other uses in WebKit. -- Regards, Ryan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev -- morrita ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] More thoughts on cleaning up the root directory
Hi, thank you for leading the reorg. Sources/ automake/ cmake/ JavaScriptCore/ JavaScriptGlue/ Platform/ (was WebCore/platform) I'd like to keep platform directory under WebCore if there is no strong reason. Classes under WebCore/platform have WebCore namespace, and the boundary between platform/ and rest of WebCore isn't clear for me. (For example, there is rendering/RenderThemeMac.mm and platform/qt/RenderThemeQt.cpp) We also often change platform and non-platform classes at the same time, that implies these tight coupling. So having these classes under same top directory will make the changelog more readable. Regards. -- morrita WebCore/ WebKit/ WebKit2/ WTF/ (was JavaScriptCore/wtf) ThirdParty/ ANGLE/ + Contents WebKitLibraries Tools/ Websites/ .gitattributes .gitignore ChangeLog Makefile Makefile.shared == UNSURE == autogen.sh Android.mk common.pri cmakeconfig.h.cmake CMakeLists.txt configure.ac GNUmakefile.am wscript DerivedSources.pro WebKit.pri WebKit.pro In this layout, I haven't merged PerformanceTests and RegressionTests for two reasons. First, the natural name, Tests, conflicts with tab-completing Tools. Second, folks so commonly access the current LayoutTests directory that it seems a bit inefficient to place it another level lower in the directory hierarchy. Comments welcome, of course. :) Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev -- morrita ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] More thoughts on cleaning up the root directory
I think moving Platform out from WebCore is great long term goal, but right now, there is simply too many layering violations for it to be feasible. For those curious, the intent is for nothing in Platform to be dependent on anything else in WebCore (eg. dom, html, rendering, loader), so something like platform/qt/RenderThemeQt.cpp would be considered a layering violation. There are bugs filed on many of these violations, but the work has not be completed. Got it. Thank you for the explanation. I filed a meta bug for tracking the layering violation. https://bugs.webkit.org/show_bug.cgi?id=51662 It would be great if anyone added dependent bugs for this. Regards. -- morrita ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Hunspell based spellchecker
On Fri, Nov 19, 2010 at 4:02 AM, Maciej Stachowiak m...@apple.com wrote: On Nov 17, 2010, at 11:44 PM, Hajime Morita wrote: On Thu, Nov 18, 2010 at 3:51 PM, Darin Adler da...@apple.com wrote On Nov 17, 2010, at 10:49 PM, Hajime Morita wrote: In other word, we should make sure that TextChecker interface can have subclasses both inside and outside WebCore. Yes, in this model the abstract base class inside WebCore will need a derived class inside Windows WebKit that then in turn calls outside of WebKit. But it is not appropriate to expose an class from WebCore directly as part of WebKit API. A WebCore class is an appropriate way for WebKit to connect to WebCore. It is not an appropriate way for WebKit to provide API. Hmm, I'm a bit confused - My last explanation looks not enough, so please let me clarify: - TextChecker is a similar to EditorClient. It will be placed in WebCore/platform/text, like EditorClient is in WebCore/page/. - And (imaginative) WebTextChecker (or TextCheckerWindows) will be in WebKit/win/WebCoreSupport, as WebEditorClient is in WebKit/win/WebCoreSupport. - WebTextChecker should use EditingDelegate, as WebEditorClient is using it now. In other word, This change will just extract TextChecker interface from EditrClient interface, and provide some default implementations of it in WebCore, as we have WebCore/page/EmptyEditorClient for EditorClient. I guess we don't have this Interface in WebCore + Implementation in WebCore and WebCoreSupport pattern yet, But I don't think it is such a huge jump from existing patterns, like Interface in WebCore + Implementation in WebCoreSupport. Does this make sense? Interface in WebCore + Implementation in WebCore and WebCoreSupport doesn't match WebKit's normal approach to layering. Our approach so far (for ports other than Chromium) has been to make it possible to link WebCore separately, and therefore only have dependencies from WebCore to WebKit, not vice versa. If WebCore functionality needs to call up to WebKit, we use an abstract interface in WebCore which WebKit then implements, i.e. the client pattern. Agreed. And I realized that my last explanation was not clear enough again ... I'm sorry for confusion. In this proposal, we will have: - WebCore::TextChecker interface (or TextCheckingClient interface, to follow our usual naming) - WebCore::TextCheckerHunspell class, implementing WebCore::TextCheckingClient - (WebKit::)WebTextChecker class, implementing WebCore::TextCheckingClient. There is no explicit dependency from WebCore to WebKit. WebCore::Editor will depend WebCore::TextCheckingClient, whose implementation might be in WebKit. -- morrita Regards, Maciej -- morrita ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Hunspell based spellchecker
Hi everyone, thank you for your feedback! Now I know there are some positive interest to Hunspell integration. So I'll start investigation and come back once I have some progress. @bflgham What would be the advantage in placing the spell checker in WebCore, as opposed to the relatively agnostic approach used via the WebKit API? Is there a performance benefit, or a means of hooking into some other part of the system not currently served by the existing spelling infrastructure? As @kwangyul.seo mentioned, the primary advantage of WebCore-ization is code sharing. Having it, you can get working integration with few effort. And yes, if you already have your own implementation, there might be no direct benefit. As a developer's standpoint, centralizing spellcheck related code into WebCore will make it much easier to work on spellchecking related codebase. As you know, touching every ports' EditingClient implementation is plain pain. It is another story though. -- morrita -Brent ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev -- morrita ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Hunspell based spellchecker
On Thu, Nov 18, 2010 at 3:33 PM, Darin Adler da...@apple.com wrote: Safari on Windows provides a spelling checker outside of WebKit. If we change the way spelling checking is organized inside WebKit, we need to preserve that feature in the WebKit used by Safari on Windows. Thank you for pointing this out. In my understanding, windows port is using EditingDelegate implementation for EditorClient. I think we can also use same EditingDlegate to implement TextChecker (or something like that) interface. In other word, we should make sure that TextChecker interface can have subclasses both inside and outside WebCore. I need to investigate more to see whether it is possible. Anyway, I'll start keeping original EditorClient API, then try to remove unnecessary methods. The change looks too large to do it at once. -- morrita ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Hunspell based spellchecker
On Thu, Nov 18, 2010 at 3:51 PM, Darin Adler da...@apple.com wrote On Nov 17, 2010, at 10:49 PM, Hajime Morita wrote: In other word, we should make sure that TextChecker interface can have subclasses both inside and outside WebCore. Yes, in this model the abstract base class inside WebCore will need a derived class inside Windows WebKit that then in turn calls outside of WebKit. But it is not appropriate to expose an class from WebCore directly as part of WebKit API. A WebCore class is an appropriate way for WebKit to connect to WebCore. It is not an appropriate way for WebKit to provide API. Hmm, I'm a bit confused - My last explanation looks not enough, so please let me clarify: - TextChecker is a similar to EditorClient. It will be placed in WebCore/platform/text, like EditorClient is in WebCore/page/. - And (imaginative) WebTextChecker (or TextCheckerWindows) will be in WebKit/win/WebCoreSupport, as WebEditorClient is in WebKit/win/WebCoreSupport. - WebTextChecker should use EditingDelegate, as WebEditorClient is using it now. In other word, This change will just extract TextChecker interface from EditrClient interface, and provide some default implementations of it in WebCore, as we have WebCore/page/EmptyEditorClient for EditorClient. I guess we don't have this Interface in WebCore + Implementation in WebCore and WebCoreSupport pattern yet, But I don't think it is such a huge jump from existing patterns, like Interface in WebCore + Implementation in WebCoreSupport. Does this make sense? -- morrita -- Darin -- morrita ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Hunspell based spellchecker
Hi WebKit folks, I'm thinking about porting Hunspell-based spellchecking code from Chromium to WebKit/WebCore. Although it's unclear whether the porting is feasible, I'd like to hear how much interest is there from other ports before starting actual work. Because the main goal is to make spellcheck available for more ports, It would be just a waste if there is no demand. For example, I heard that GTK+ has GtkSpell, which is based on Enchant. Because our code is based on Hunspell, GtkSpell based integration is out of scope of this proposal... I have no idea about Qt, EFL, etc. BTW, here is an under-half-baked-rough plan: - Extract spellcheck related methods on EditorClient, to interface (or abstract class) named, say, platform/text/TextChecker. - with keeping existing method, for compatibility - Add a getter like TextChecker* textChecker() = 0; to EditorClient. - Implement TextCheckerHunspell, a subclass of TextCheckerHunspell - TextCheckerHunspellChromium and some other variants will also be added, to make Chromium specific hooks. - (optional) Move Mac's spellchecker implementation from WebCoreSupport/WebEditorClient to platform/text/TextCheckerCocoa, another subclass of TextChecker. - (optional) Remove legacy methods on EditorClient This approach would make spellchecker pluggable, so WebKit can choose preferable spellchecker at runtime with this. (For example, Chromium port wants to use both Hunspell and system spellchecker. GTK port might want use Enchant and Hunspell.) Is this beneficial for your port? Are there other design possibilities? Any feedback is welcome. -- morrita ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Sharing WebKit mocks across platforms
Hi Alexey, thank you for sharing your thought. I agree that using platform APIs for testing is better than using mocks. On the other hand, I believe the automated testing is our invaluable assert. And some real API is hard to automate. Here is a conflict. I think we need both. Currently WebKit has3 mocks under platform/mock - DeviceOrientationClientMock - GeolocationServiceMock - SpeechInputClientMock It looks that these features are hard to automate without mocks. Another advantage of mocked test is that it is easier to have high code coverage than others, due to the ease to control which mocks provide. So having these mocks somewhere out of WebCore looks a reasonable compromise if we have some manual test counterparts for mocked automated tests. But I'd like to hear the implementors voice, as Alexey hoped so. -- morrita On Thu, Nov 11, 2010 at 2:53 AM, Alexey Proskuryakov a...@webkit.org wrote: Sorry for a delayed response - I hoped for someone else to weigh in. This approach is certainly better than having code in shipping WebCore. But I still think that testing via platform APIs is much more desirable than implementing and maintaining a separate pseudo-API for mocks. This can't be too bad for productivity either - the social contract seems to be that you implement DumpRenderTree for one or two platforms at most, and file bugs for others. - WBR, Alexey Proskuryakov 27.10.2010, в 22:08, Hajime Morita написал(а): Hi Alexey, thank you for revising this topic! I understand your concern about having a testing infrastructure inside the production code. On the other hand, having separate but similar mocks for each port hurts our productivity. And we cannot automate testing without mocks anyway. So how about to have separate WebCoreTesting library/framework? The WebCoreTesting will: - access WebCore types directly, as WebKit library does - have mock implementations of WebCore-provided interfaces (abstract classes) and - WebCore will provide abstract classes and injection points for their intenaces, but not provide class implementations - WebKit will provide a priviate method to enable the mocks, which uses WebKitTesting. WebKitTesting library will be linked lazily (using weak symbol mechanism for Mac, or dlopen() family for other ports.) In this approach, we - can split the testing infrastructure out from the production code, just by removing WebCoreTesting library. - can share mock implementations between ports. Even with this approach, some redundancy remains in WebCore, like abstract class for mocks. But actual code, which is a possible cause of vulnerability, can be removed from the production. I once prototyped that approach for introducing WebCore::LayoutTestController. So the patch might help to see what I meant to say: https://bug-42612-attachments.webkit.org/attachment.cgi?id=63403 (Note this patch has rough edges and need to polish anyway.) Believing what I proposed above is a reasonable tradeoff between security/efficiency and productivity, I wonder there might be other possibilities to explore. So I'd love to hear from you and any folks who have interest. Regards. -- morrita On Thu, Oct 28, 2010 at 4:07 AM, Alexey Proskuryakov a...@webkit.org wrote: 02.08.2010, в 4:38, Alexey Proskuryakov написал(а): 29.07.2010, в 8:16, Adam Barth написал(а): Plumbing this mock API all the way through WebKit for each port seems like a waste. One benefit of this is that it makes us test the API layer. Another one is that it gives WebKit developers better familiarity with APIs - that's not as minor as it sounds, as some of us (including myself) have limited knowledge of WebKit APIs, even for their favorite platform. It certainly seems like a waste when private methods are added just for DumpRenderTree support. But maybe it has prompted an API introduction a few times before, I just don't know. This is all getting much better with WebKit2's cross-platform API, although of course we'll need to support current APIs for a long time. This thread died, but I still don't feel good about mock objects in WebCore. Having test infrastructure in WebCore means shipping unused code in the framework, and as mentioned before, we lack testing of the API layer. We're now getting more mock objects in the tree, such as one for speech synthesis testing. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev -- morrita -- morrita ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Sharing WebKit mocks across platforms
Hi Alexey, thank you for revising this topic! I understand your concern about having a testing infrastructure inside the production code. On the other hand, having separate but similar mocks for each port hurts our productivity. And we cannot automate testing without mocks anyway. So how about to have separate WebCoreTesting library/framework? The WebCoreTesting will: - access WebCore types directly, as WebKit library does - have mock implementations of WebCore-provided interfaces (abstract classes) and - WebCore will provide abstract classes and injection points for their intenaces, but not provide class implementations - WebKit will provide a priviate method to enable the mocks, which uses WebKitTesting. WebKitTesting library will be linked lazily (using weak symbol mechanism for Mac, or dlopen() family for other ports.) In this approach, we - can split the testing infrastructure out from the production code, just by removing WebCoreTesting library. - can share mock implementations between ports. Even with this approach, some redundancy remains in WebCore, like abstract class for mocks. But actual code, which is a possible cause of vulnerability, can be removed from the production. I once prototyped that approach for introducing WebCore::LayoutTestController. So the patch might help to see what I meant to say: https://bug-42612-attachments.webkit.org/attachment.cgi?id=63403 (Note this patch has rough edges and need to polish anyway.) Believing what I proposed above is a reasonable tradeoff between security/efficiency and productivity, I wonder there might be other possibilities to explore. So I'd love to hear from you and any folks who have interest. Regards. -- morrita On Thu, Oct 28, 2010 at 4:07 AM, Alexey Proskuryakov a...@webkit.org wrote: 02.08.2010, в 4:38, Alexey Proskuryakov написал(а): 29.07.2010, в 8:16, Adam Barth написал(а): Plumbing this mock API all the way through WebKit for each port seems like a waste. One benefit of this is that it makes us test the API layer. Another one is that it gives WebKit developers better familiarity with APIs - that's not as minor as it sounds, as some of us (including myself) have limited knowledge of WebKit APIs, even for their favorite platform. It certainly seems like a waste when private methods are added just for DumpRenderTree support. But maybe it has prompted an API introduction a few times before, I just don't know. This is all getting much better with WebKit2's cross-platform API, although of course we'll need to support current APIs for a long time. This thread died, but I still don't feel good about mock objects in WebCore. Having test infrastructure in WebCore means shipping unused code in the framework, and as mentioned before, we lack testing of the API layer. We're now getting more mock objects in the tree, such as one for speech synthesis testing. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev -- morrita ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Some landed patches have incorrect date in commit messages and ChangeLog
Hi, I'm sorry that I did it yesterday. Usually I use webkit-patch. But that patch had 2 bug URLs and webkit-patch didn't work for it. So I rewrote ChangeLogs - with the wrong way. If webkit-patch land support --bug-id, it might be helpful for my case. Thanks. -- morita On Tue, Aug 10, 2010 at 2:51 AM, Jian Li jia...@chromium.org wrote: Hi, I noticed that several patches landed recently have the incorrect date put in the commit messages and ChangeLog. Please fix the incorrect information in ChangeLog. For the commit messages, anyone know if we can fix them or not? Please make sure the correct date is used when you land your patch manually. Thanks. Jian ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev -- morita ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Adding window.layoutTestInspector
Hi folks, I posted a patch: https://bugs.webkit.org/show_bug.cgi?id=42612 Any feedbacks are appreciated. -- morita On Wed, Jul 21, 2010 at 2:33 PM, Hajime Morita morr...@google.com wrote: Hi Maciej, thanks much for sharing your thought. Overall, it totally makes sense. And we need an action as Ojan mentioned. Here is some ideas; (1) It seems a little odd that we'll end up with two different objects that have similar names and a very similar purpose, but just differ in how they are implemented. Maybe there's a way to define layoutTestController in WebCore and have DumpRenderTree extend it. It looks fine. A prototype patch will come shortly. (2) It does seem like for some test-specific methods, implementing then in WebCore would be simpler and would save the work of plumbing them through the WebKit layers. Yeah, it's the main point of this proposal! (3) On the other hand, LayoutTestController seems like it has too much stuff in it. Originally DumpRenderTree exposed a very modest set of functionality, mostly to control output (dumpAsText) or to emulate things that you could do by hand when running the test in the browser (waitUntilDone, eventSender). Nowadays, there are dozens of methods. A lot of them are used in only one or two tests. And in many cases, the methods have no interactive equivalent, so a lot of our tests are not runnable in the browser at all. Those seem like bad trends. Maybe instead of making it easier to add to LayoutTestController, we should look at whether we can consolidate functionality, factor it into more objects, and find ways to test things that don't require quite so much custom functionality. Looks several points here and I think we can tackle them separetely: - (3-1): LayoutTestController is too large and need to be factored out - (3-2): We shoud allow our tests to run interactively in the browser. For (3-1), once we can implement test objects inside WebCore, it will become easier to do so because we can use our internal mechanism like IDL-based binding generation. As an example, defining WebSettings JS object to expose Settings parameter would be fine. 16 of 120 LayoutTestController APIs are Settings/WebPreferences setters. WebView and WebFrame also have several wrapper APIs on LayoutTestController. Tackling (3-2) looks harder than for (3-1). As WebKit grows, no single browser cannot (and doesn't need to) access all of WebKit features. Each of them uses different subset of features. Browsers themselves also behave differently. There are over 20 flags on LayoutTestController to control its behavior, which implies how our browsers collaborate WebKit in many different ways. So problem (3-2) is not always of LayoutTestController. It may just reflect the fact of, say, divergence of our codebase and use-cases. On the other hand, I agree that we need to run our tests interactively. One possible idea is: Adding a switch to the inspector that make LayoutTestController (and associated objects) accessible from the page context. Once we have LayoutTestController inside WebCore, these objects will be available without DRT. It might not solve the root problem. But it would provide the way to workround. -- morita On Tue, Jul 20, 2010 at 2:51 PM, Maciej Stachowiak m...@apple.com wrote: Darin and I discussed this proposal, and we had a few thoughts to share: (1) It seems a little odd that we'll end up with two different objects that have similar names and a very similar purpose, but just differ in how they are implemented. Maybe there's a way to define layoutTestController in WebCore and have DumpRenderTree extend it. (2) It does seem like for some test-specific methods, implementing then in WebCore would be simpler and would save the work of plumbing them through the WebKit layers. (3) On the other hand, LayoutTestController seems like it has too much stuff in it. Originally DumpRenderTree exposed a very modest set of functionality, mostly to control output (dumpAsText) or to emulate things that you could do by hand when running the test in the browser (waitUntilDone, eventSender). Nowadays, there are dozens of methods. A lot of them are used in only one or two tests. And in many cases, the methods have no interactive equivalent, so a lot of our tests are not runnable in the browser at all. Those seem like bad trends. Maybe instead of making it easier to add to LayoutTestController, we should look at whether we can consolidate functionality, factor it into more objects, and find ways to test things that don't require quite so much custom functionality. I'll add on my own behalf that layoutTestInspector doesn't seem like a great name and doesn't express the relationship to layoutTestController. It's not used to examine layout tests. Regards, Maciej On Jul 14, 2010, at 10:16 PM, Hajime Morita wrote: Hi WebKit folks, I'm planning to add
Re: [webkit-dev] Adding window.layoutTestInspector
Hi Maciej, thanks much for sharing your thought. Overall, it totally makes sense. And we need an action as Ojan mentioned. Here is some ideas; (1) It seems a little odd that we'll end up with two different objects that have similar names and a very similar purpose, but just differ in how they are implemented. Maybe there's a way to define layoutTestController in WebCore and have DumpRenderTree extend it. It looks fine. A prototype patch will come shortly. (2) It does seem like for some test-specific methods, implementing then in WebCore would be simpler and would save the work of plumbing them through the WebKit layers. Yeah, it's the main point of this proposal! (3) On the other hand, LayoutTestController seems like it has too much stuff in it. Originally DumpRenderTree exposed a very modest set of functionality, mostly to control output (dumpAsText) or to emulate things that you could do by hand when running the test in the browser (waitUntilDone, eventSender). Nowadays, there are dozens of methods. A lot of them are used in only one or two tests. And in many cases, the methods have no interactive equivalent, so a lot of our tests are not runnable in the browser at all. Those seem like bad trends. Maybe instead of making it easier to add to LayoutTestController, we should look at whether we can consolidate functionality, factor it into more objects, and find ways to test things that don't require quite so much custom functionality. Looks several points here and I think we can tackle them separetely: - (3-1): LayoutTestController is too large and need to be factored out - (3-2): We shoud allow our tests to run interactively in the browser. For (3-1), once we can implement test objects inside WebCore, it will become easier to do so because we can use our internal mechanism like IDL-based binding generation. As an example, defining WebSettings JS object to expose Settings parameter would be fine. 16 of 120 LayoutTestController APIs are Settings/WebPreferences setters. WebView and WebFrame also have several wrapper APIs on LayoutTestController. Tackling (3-2) looks harder than for (3-1). As WebKit grows, no single browser cannot (and doesn't need to) access all of WebKit features. Each of them uses different subset of features. Browsers themselves also behave differently. There are over 20 flags on LayoutTestController to control its behavior, which implies how our browsers collaborate WebKit in many different ways. So problem (3-2) is not always of LayoutTestController. It may just reflect the fact of, say, divergence of our codebase and use-cases. On the other hand, I agree that we need to run our tests interactively. One possible idea is: Adding a switch to the inspector that make LayoutTestController (and associated objects) accessible from the page context. Once we have LayoutTestController inside WebCore, these objects will be available without DRT. It might not solve the root problem. But it would provide the way to workround. -- morita On Tue, Jul 20, 2010 at 2:51 PM, Maciej Stachowiak m...@apple.com wrote: Darin and I discussed this proposal, and we had a few thoughts to share: (1) It seems a little odd that we'll end up with two different objects that have similar names and a very similar purpose, but just differ in how they are implemented. Maybe there's a way to define layoutTestController in WebCore and have DumpRenderTree extend it. (2) It does seem like for some test-specific methods, implementing then in WebCore would be simpler and would save the work of plumbing them through the WebKit layers. (3) On the other hand, LayoutTestController seems like it has too much stuff in it. Originally DumpRenderTree exposed a very modest set of functionality, mostly to control output (dumpAsText) or to emulate things that you could do by hand when running the test in the browser (waitUntilDone, eventSender). Nowadays, there are dozens of methods. A lot of them are used in only one or two tests. And in many cases, the methods have no interactive equivalent, so a lot of our tests are not runnable in the browser at all. Those seem like bad trends. Maybe instead of making it easier to add to LayoutTestController, we should look at whether we can consolidate functionality, factor it into more objects, and find ways to test things that don't require quite so much custom functionality. I'll add on my own behalf that layoutTestInspector doesn't seem like a great name and doesn't express the relationship to layoutTestController. It's not used to examine layout tests. Regards, Maciej On Jul 14, 2010, at 10:16 PM, Hajime Morita wrote: Hi WebKit folks, I'm planning to add window.layoutTestInspector or something like that to DRT. And I'd like to hear your opinions. Background: Adding new method to LayoutTestController is hard. It - requires to add new WebKit API to each ports, when the method
Re: [webkit-dev] Adding window.layoutTestInspector
Hi Ojan, thank you for the response!
Let me summarize to make sure I understand the proposal: Expose a new object
to layout tests that is entirely in WebCore instead of in the DRT layer.
Then, only put things in layoutTestController that need to be at the WebKit
layer, e.g. notifyDone, waitUntilDone, etc. APIs that only need to touch
WebCore can live in WebCore.
Exactly.
I'd like to note that I have no intention to remove existing
LayoutTestController APIs.
Overall, I like the idea of making it easier to add bits exposed just for
the sake of testing. Right now, it's really difficult to make simple
extensions to layoutTestController because they need to be made many times
over for each platform and there are many bits in layoutTestController that
only need to touch WebCore. Spelling/grammer markers is a good example.
setEditingBehavior is another good one.
Agreed. Exposing setEditingBehavior will be good for testing around editing
selection.
Re-defining enum on the WebKit layer is essentially redundant, and nice to
avoid.
I filed the bug for this: https://bugs.webkit.org/show_bug.cgi?id=42612
A patch will come shortly.
--
morita
Ojan
On Wed, Jul 14, 2010 at 10:16 PM, Hajime Morita morr...@google.comwrote:
Hi WebKit folks,
I'm planning to add window.layoutTestInspector or something like that to
DRT.
And I'd like to hear your opinions.
Background:
Adding new method to LayoutTestController is hard. It
- requires to add new WebKit API to each ports, when the method is to
access WebCore.
- requires to export extra WebCore symbols to access it from WebKit
API implementation.
- cannot use WebIDL so we need to write binding code manually.
In some case, these steps are unavoidable.
But in some other case, especially when we just want to access WebCore
from the test, we might be able to skip these steps.
A concrete example (my first motivation) is to test DocumentMarker
for http://webkit.org/b/41423.
DocumentMarker is WebCore's internal state and cannot access neither
from DOM nor LayoutTestController.
To test it,
- the first idea is to use a pixel test.
But it has some shortcomings as you know well.
- The second idea is to extend render tree's dump format to
include markers. But it is also platform-specific,
and hard to interpret for humans.
- The third idea is to add an API to LayoutTestController.
But it is hard as I mentioned above.
Is there another way? DocumentMarker is
- WebCore's internal state,
- so we don't need to inspect it except for testing purpose,
- so it's better to avoid an extra WebKit API for that.
I think there are similar demands other than for DocumentMarker,
and it might be worth to invest a common way to handle them.
Plans:
To deal with such cases, we can add a test-specific object named
LayoutTestInspector to window object. (The name is tentative.)
With this object, We'll be able to write a LayoutTest like:
if (window.layoutTestInspector) {
var target = document.getElementById(target)
var markerStr = layoutTestInspector.nodeMarkerString(target);
if (markerStr == Spelling:0:6)
log(PASS);
else
log(FAIL);
}
Here is a plan to do this:
- LayoutTestInspector will be defined in WebCore,
and implemented as a usual DOM object using WebIDL.
(placed under, for example, WebCore/page/LayoutTestInspector.{idl,h,cpp})
- window object will expose a non-enumerable
windows.layoutTestInspector property
for that.
- Settings::m_enableLayoutTestInspector will control
windows.layoutTestInspector
availability. This flag should be true only on DRT.
Tests with LayoutTestInspector would have several advantages:
- Compared to LayoutTestController,
we don't need to add new APIs to WebKit layer for test purpose.
- Compared to LayoutTestController,
we don't need to export extra WebCore APIs to WebKit layer.
- Compared to Render-tree dump,
the test can be more portable, focused and understandable.
But there are some concerns:
- WebCore need to have a test-specific code, that might be a waste of
space.
Test-specific WebKit APIs would have a same problem, though.
- LayoutTestInspector may introduce some potential security risks.
I have no idea about this area.
Do you have any other use-cases or better approaches?
Are there concerns I've missed? Do we have similar discussions in the
past?
Any ideas/suggestions are welcome.
If there are no strong objections, I'll start to work on this.
Regards.
--
morita
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
--
morita
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Adding window.layoutTestInspector
Hi WebKit folks,
I'm planning to add window.layoutTestInspector or something like that to DRT.
And I'd like to hear your opinions.
Background:
Adding new method to LayoutTestController is hard. It
- requires to add new WebKit API to each ports, when the method is to
access WebCore.
- requires to export extra WebCore symbols to access it from WebKit
API implementation.
- cannot use WebIDL so we need to write binding code manually.
In some case, these steps are unavoidable.
But in some other case, especially when we just want to access WebCore
from the test, we might be able to skip these steps.
A concrete example (my first motivation) is to test DocumentMarker
for http://webkit.org/b/41423.
DocumentMarker is WebCore's internal state and cannot access neither
from DOM nor LayoutTestController.
To test it,
- the first idea is to use a pixel test.
But it has some shortcomings as you know well.
- The second idea is to extend render tree's dump format to
include markers. But it is also platform-specific,
and hard to interpret for humans.
- The third idea is to add an API to LayoutTestController.
But it is hard as I mentioned above.
Is there another way? DocumentMarker is
- WebCore's internal state,
- so we don't need to inspect it except for testing purpose,
- so it's better to avoid an extra WebKit API for that.
I think there are similar demands other than for DocumentMarker,
and it might be worth to invest a common way to handle them.
Plans:
To deal with such cases, we can add a test-specific object named
LayoutTestInspector to window object. (The name is tentative.)
With this object, We'll be able to write a LayoutTest like:
if (window.layoutTestInspector) {
var target = document.getElementById(target)
var markerStr = layoutTestInspector.nodeMarkerString(target);
if (markerStr == Spelling:0:6)
log(PASS);
else
log(FAIL);
}
Here is a plan to do this:
- LayoutTestInspector will be defined in WebCore,
and implemented as a usual DOM object using WebIDL.
(placed under, for example, WebCore/page/LayoutTestInspector.{idl,h,cpp})
- window object will expose a non-enumerable
windows.layoutTestInspector property
for that.
- Settings::m_enableLayoutTestInspector will control windows.layoutTestInspector
availability. This flag should be true only on DRT.
Tests with LayoutTestInspector would have several advantages:
- Compared to LayoutTestController,
we don't need to add new APIs to WebKit layer for test purpose.
- Compared to LayoutTestController,
we don't need to export extra WebCore APIs to WebKit layer.
- Compared to Render-tree dump,
the test can be more portable, focused and understandable.
But there are some concerns:
- WebCore need to have a test-specific code, that might be a waste of space.
Test-specific WebKit APIs would have a same problem, though.
- LayoutTestInspector may introduce some potential security risks.
I have no idea about this area.
Do you have any other use-cases or better approaches?
Are there concerns I've missed? Do we have similar discussions in the past?
Any ideas/suggestions are welcome.
If there are no strong objections, I'll start to work on this.
Regards.
--
morita
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Announcing WebKit2
Hi, It looks supporting multi-threaded model. See WebProcessLauncher.mm for detail. -- morita On Fri, Apr 9, 2010 at 9:11 PM, zaheer ahmad zaheer@gmail.com wrote: hi , why only multi-process and not multi-thread like android. It is useful for mobile environments. thanks, Zaheer On Fri, Apr 9, 2010 at 5:15 PM, Maciej Stachowiak m...@apple.com wrote: On Apr 9, 2010, at 3:40 AM, Maciej Stachowiak wrote: On Apr 9, 2010, at 3:36 AM, Jeremy Orlow wrote: I hope this post clarifies why the Chromium WebKit port is not really a viable solution for our needs as it stands today. It was _very_ helpful. Thanks for taking the time to explain it so well. (It might be worth moving some of that description and diagrams into the Wiki as well.) Yeah, I'm trying to put some of this info in the wiki as we speak. :-) I made a bunch of updates to the wiki page: http://trac.webkit.org/wiki/WebKit2 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 -- morita ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] To start meter element implementation
Hi folks, I'm planning to work on HTML5 meter element, which is filed on https://bugs.webkit.org/show_bug.cgi?id=37074 . Although there seems no effort for that element at this time, The progress element looks similar to meter. So I'll try to go the way as progress has been going and share some part of codebase hopefully. Any suggestions and advices are welcome. Thanks in advance. -- morita ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] To start meter element implementation
Maciej, Darin, thank you for your feedback! I believe progress is only currently enabled for the Qt port, in part because no one has implemented the other themes. Yes, there are only Qt port and Mac port available now and I agree with you that well-behaving one new element is more useful than half-baked two. So OK, I'll start porting progress to Chromium before I start working on meter. On stylability and accessibility, currently I have no idea how to implement these, and how hard they are. I would investigate them later after chromium port, or original progress author (Yael) might have some ideas or code for that, which would be very helpful. I'll follow the progress of our progress implementation. -- morita On Mon, Apr 5, 2010 at 11:31 AM, Maciej Stachowiak m...@apple.com wrote: On Apr 4, 2010, at 7:23 PM, Hajime Morita wrote: Hi folks, I'm planning to work on HTML5 meter element, which is filed on https://bugs.webkit.org/show_bug.cgi?id=37074 . Although there seems no effort for that element at this time, The progress element looks similar to meter. So I'll try to go the way as progress has been going and share some part of codebase hopefully. Any suggestions and advices are welcome. Thanks in advance. I don't know if there is much opportunity for code sharing. meter is pretty different from progress. It has a different purpose and should have a different default appearance. I believe progress is only currently enabled for the Qt port, in part because no one has implemented the other themes. I believe the big challenges to have really complete versions of meter and progress include: 1) Fully stylable custom look with CSS - it's hard to figure out how to do this, because these elements are both parameterized with an arbitrary level. 2) Accessibility support - we can't call these done until they offer at least as good an accessibility experience as explicit ARIA markup. I think it would be a good idea to truly finish progress first before embarking on meter. I would rather have one truly complete new element than two that are half-done. Regards, Maciej -- morita ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
