Re: [webkit-dev] Enabling the HTML5 tree builder soon
For future reference, iBench can be found here: ftp://ftp.pcmag.com/Benchmarks/i-bench/ib50.exe However, it requires a Windows system with IIS to set up the server, and is generally a hassle to set up as Stephanie said. Cheers, Maciej On Jul 28, 2010, at 10:09 PM, Adam Barth wrote: slewis++ On Thu, Jul 29, 2010 at 3:15 AM, Stephanie Lewis sle...@apple.com wrote: I believe it is somewhere, but the setup is a hassle, so I'll run it tomorrow for you. -- Stephanie On Jul 28, 2010, at 8:13 PM, Adam Barth wrote: On Wed, Jul 28, 2010 at 7:39 AM, Maciej Stachowiak m...@apple.com wrote: On Jul 27, 2010, at 9:06 PM, Stephanie Lewis wrote: I measure it as a 1% win on the PLT. Might be a good idea to test HTML iBench as well. Sure. I'd be happy to. Is that benchmark available publicly? Adam ___ 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
Thanks for bring this question to the list. I don't have a strong opinion here, but I want to make sure we think project-wide and pick something scalable. This discussion is also related to the discussion about adding something like a layoutTestController object to WebCore. Plumbing this mock API all the way through WebKit for each port seems like a waste. If we had something like a WebCore::LayoutTestController, it would make a lot more sense to expose that functionality there. Adam On Wed, Jul 28, 2010 at 11:30 AM, Steve Block stevebl...@google.com wrote: I'm in the process of adding a mock client for DeviceOrientation, which will be used in DumpRenderTree to test the feature. In order to share the mock across platforms, I'd like to add the mock to WebCore/platform/mock. An interface to the mock will have to be exposed to the embedder through the platform's WebKit API, so that it can be configured by DRT, eg ... mWebView.getDeviceOrientationClientMock().setOrientation(...); To avoid each platform having to produce it's own WebKit wrapper for the mock, I'm considering adding a common WebKit wrapper, perhaps to WebKit/common, and I wanted to get some feedback on the idea. The mock would be shared between all C++ WebKit platforms. (Note that this is for convenience only, a platform could equally use it's own WebKit wrapper around the WebCore mock (eg Mac may do so in ObjectiveC), or use its own mock altogether.) Of course we also need WebKit wrappers for all of the non-POD types used by the mock's interface, and these have to be common between all platforms. One obvious potential difficulty is the wrapper for WebCore::String. Each platforms already has a wrapper for this type, but there's no guarantee of interoperability, so we'd need to write a new common interface if we're to use the string type. If a wrapper for string ends up being too problematic, the approach could still be used for mocks that don't need the string type (of which DeviceOrientation is one), but the approach then seems less compelling. Do people think that this is a reasonable proposal and worth pursuing? Has there been any attempt to do anything similar before? Or is any attempt to write this kind of common WebKit code not worth the effort and destined to failure? You can see the work in progress for DeviceOrientation at https://bugs.webkit.org/show_bug.cgi?id=39589 and a similar patch for SpeechInput mocks at https://bugs.webkit.org/show_bug.cgi?id=42603 I'd appreciate any feedback you may have. Thanks, Steve -- Google UK Limited Registered Office: Belgrave House, 76 Buckingham Palace Road, London SW1W 9TQ Registered in England Number: 3977902 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Handling IME composition events
On Thu, Jul 29, 2010 at 3:13 AM, Oliver Hunt oli...@apple.com wrote: On Jul 28, 2010, at 8:45 AM, Joone Hur wrote: 3) Keyboard events should not be dispatched during a composition. Key events must be sent while an IME is active otherwise sites break. IIRC you get keydown and keyup events, but not keypress. The keydown event when an IME is active has charCode 229 in order to be compatible with IE. In case of Firefox, it doesn't fire any keyboard events during a composition. Therefore, a Mozilla developer mentioned on a bug about no keyboard events during a Hangul composition as follows, I still think that we shouldn't fire any key events during composing. The compositionupdate event is enough for this issue. https://bugzilla.mozilla.org/show_bug.cgi?id=354358#c24 Firefox4.0b1 also doesn't fire any keyboard events after compositionstart event. = You can find a test result from http://bit.ly/99tkd0 Of course, there has been a compatibility issue of detecting composition states in case of Firefox compared to IE. However, I think that composition events seem enough without keyboard events during a IME composition. Because many Korean web developers have known this issue so they have used a workaround to avoid it. We need a consensus on this issue between WebKit and Mozilla developers. Thanks for your feedback. Joone ___ 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
With a WebCore::LayoutTestController, would there be a need for code in WebKit to convert the call parameters from WebKit types (which DRT uses) to WebCore types (which the mocks may use) ? If yes seems like we need wrappers to proxy the mock calls anyway on different platforms.. Cheers Satish On Thu, Jul 29, 2010 at 4:16 PM, Adam Barth aba...@webkit.org wrote: Thanks for bring this question to the list. I don't have a strong opinion here, but I want to make sure we think project-wide and pick something scalable. This discussion is also related to the discussion about adding something like a layoutTestController object to WebCore. Plumbing this mock API all the way through WebKit for each port seems like a waste. If we had something like a WebCore::LayoutTestController, it would make a lot more sense to expose that functionality there. Adam On Wed, Jul 28, 2010 at 11:30 AM, Steve Block stevebl...@google.com wrote: I'm in the process of adding a mock client for DeviceOrientation, which will be used in DumpRenderTree to test the feature. In order to share the mock across platforms, I'd like to add the mock to WebCore/platform/mock. An interface to the mock will have to be exposed to the embedder through the platform's WebKit API, so that it can be configured by DRT, eg ... mWebView.getDeviceOrientationClientMock().setOrientation(...); To avoid each platform having to produce it's own WebKit wrapper for the mock, I'm considering adding a common WebKit wrapper, perhaps to WebKit/common, and I wanted to get some feedback on the idea. The mock would be shared between all C++ WebKit platforms. (Note that this is for convenience only, a platform could equally use it's own WebKit wrapper around the WebCore mock (eg Mac may do so in ObjectiveC), or use its own mock altogether.) Of course we also need WebKit wrappers for all of the non-POD types used by the mock's interface, and these have to be common between all platforms. One obvious potential difficulty is the wrapper for WebCore::String. Each platforms already has a wrapper for this type, but there's no guarantee of interoperability, so we'd need to write a new common interface if we're to use the string type. If a wrapper for string ends up being too problematic, the approach could still be used for mocks that don't need the string type (of which DeviceOrientation is one), but the approach then seems less compelling. Do people think that this is a reasonable proposal and worth pursuing? Has there been any attempt to do anything similar before? Or is any attempt to write this kind of common WebKit code not worth the effort and destined to failure? You can see the work in progress for DeviceOrientation at https://bugs.webkit.org/show_bug.cgi?id=39589 and a similar patch for SpeechInput mocks at https://bugs.webkit.org/show_bug.cgi?id=42603 I'd appreciate any feedback you may have. Thanks, Steve -- Google UK Limited Registered Office: Belgrave House, 76 Buckingham Palace Road, London SW1W 9TQ Registered in England Number: 3977902 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Name nitpick: layout tests
Hi folks. WebKit regression tests are in a directory named LayoutTests. The object the tests uses to do special test-specific operations is layoutTestController. Both of these names are unwanted baggage, left over from when the test machinery was only good for testing layout. The directory should be eventually be named Tests or WebKitTests or RegressionTests. Eric Seidel can probably remember talking this over with me the day after we added the LayoutTests directory; sorry that I never fixed it! The object should be named testController, or perhaps someone can think of an even better name. A super-short one would probably be OK; the only practical problem is that we don’t want to choose a name that is likely to conflict with something we’ll add to HTML5 in the future. (I would have used the phrase “the web platform” instead of HTML5, which would be way better for pedants, but I think it would confuse others.) While we may be stuck with the current names for some time, we should not introduce new uses of the word layout in the context of our regression test machinery. That’s why the script is named run-webkit-tests, not run-layout-tests. I renamed that one in time, before we went wide with the WebKit project. It’s my fault we didn’t rename those other things sooner. As a first step, I suggest we make the test controller object available under its new name, and start using that name in new tests. Once we convert all the tests, we can drop the layoutTestController name entirely. Your thoughts? -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Name nitpick: layout tests
On Thu, Jul 29, 2010 at 10:59 AM, Darin Adler da...@apple.com wrote: The directory should be eventually be named Tests or WebKitTests or RegressionTests. Eric Seidel can probably remember talking this over with me the day after we added the LayoutTests directory; sorry that I never fixed it! This sounds like an easy fix compared to converting all the existing tests. I do like the idea of renaming it since some tests aren't really testing the layout. As a first step, I suggest we make the test controller object available under its new name, and start using that name in new tests. Once we convert all the tests, we can drop the layoutTestController name entirely. But I'm not sure if converting all the existing tests is feasible or worth the effort. Is there any practical problem other than being semantically wrong? Best, Ryosuke Niwa ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Name nitpick: layout tests
On Jul 29, 2010, at 11:09 AM, Ryosuke Niwa wrote: But I'm not sure if converting all the existing tests is feasible or worth the effort. Is there any practical problem other than being semantically wrong? This is not something we have to decide up front. Converting the existing tests is not only feasible but quite easy, but I agree that it’s not important. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Name nitpick: layout tests
On Thu, Jul 29, 2010 at 10:59 AM, Darin Adler da...@apple.com wrote: Hi folks. WebKit regression tests are in a directory named LayoutTests. The object the tests uses to do special test-specific operations is layoutTestController. Both of these names are unwanted baggage, left over from when the test machinery was only good for testing layout. The directory should be eventually be named Tests or WebKitTests or RegressionTests. Eric Seidel can probably remember talking this over with me the day after we added the LayoutTests directory; sorry that I never fixed it! The object should be named testController, or perhaps someone can think of an even better name. A super-short one would probably be OK; the only practical problem is that we don’t want to choose a name that is likely to conflict with something we’ll add to HTML5 in the future. (I would have used the phrase “the web platform” instead of HTML5, which would be way better for pedants, but I think it would confuse others.) While we may be stuck with the current names for some time, we should not introduce new uses of the word layout in the context of our regression test machinery. That’s why the script is named run-webkit-tests, not run-layout-tests. I renamed that one in time, before we went wide with the WebKit project. It’s my fault we didn’t rename those other things sooner. As a first step, I suggest we make the test controller object available under its new name, and start using that name in new tests. Once we convert all the tests, we can drop the layoutTestController name entirely. Your thoughts? -- Darin Sounds good to me. -- Dirk ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Name nitpick: layout tests
I'm fine with it as well; the name confuses a lot of new contributors. Kenneth On Thu, Jul 29, 2010 at 3:15 PM, Dirk Pranke dpra...@chromium.org wrote: On Thu, Jul 29, 2010 at 10:59 AM, Darin Adler da...@apple.com wrote: Hi folks. WebKit regression tests are in a directory named LayoutTests. The object the tests uses to do special test-specific operations is layoutTestController. Both of these names are unwanted baggage, left over from when the test machinery was only good for testing layout. The directory should be eventually be named Tests or WebKitTests or RegressionTests. Eric Seidel can probably remember talking this over with me the day after we added the LayoutTests directory; sorry that I never fixed it! The object should be named testController, or perhaps someone can think of an even better name. A super-short one would probably be OK; the only practical problem is that we don’t want to choose a name that is likely to conflict with something we’ll add to HTML5 in the future. (I would have used the phrase “the web platform” instead of HTML5, which would be way better for pedants, but I think it would confuse others.) While we may be stuck with the current names for some time, we should not introduce new uses of the word layout in the context of our regression test machinery. That’s why the script is named run-webkit-tests, not run-layout-tests. I renamed that one in time, before we went wide with the WebKit project. It’s my fault we didn’t rename those other things sooner. As a first step, I suggest we make the test controller object available under its new name, and start using that name in new tests. Once we convert all the tests, we can drop the layoutTestController name entirely. Your thoughts? -- Darin Sounds good to me. -- Dirk ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev -- Kenneth Rohde Christiansen Technical Lead / Senior Software Engineer Qt Labs Americas, Nokia Technology Institute, INdT Phone +55 81 8895 6002 / E-mail kenneth.christiansen at openbossa.org ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Handling IME composition events
On Thu, Jul 29, 2010 at 9:18 AM, Joone Hur jo...@kldp.org wrote: On Thu, Jul 29, 2010 at 3:13 AM, Oliver Hunt oli...@apple.com wrote: On Jul 28, 2010, at 8:45 AM, Joone Hur wrote: 3) Keyboard events should not be dispatched during a composition. Key events must be sent while an IME is active otherwise sites break. IIRC you get keydown and keyup events, but not keypress. The keydown event when an IME is active has charCode 229 in order to be compatible with IE. However, I think that composition events seem enough without keyboard events during a IME composition. If were were designing these APIs from scratch, that might be the case. But WebKit only recently added composition events. We have been firing key events for a long time. If we stopped firing them, a lot of sites would break in WebKit browsers. So, not firing them is not an option. We need a consensus on this issue between WebKit and Mozilla developers. I don't think we could reasonably stop firing key events. Too many sites would break. Ojan ___ 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
WebCore::LayoutTestController would be exposed to JavaScript running in LayoutTests directly (like the DOM), so we can skip the type conversions. Adam On Thu, Jul 29, 2010 at 9:20 AM, Satish Sampath sat...@google.com wrote: With a WebCore::LayoutTestController, would there be a need for code in WebKit to convert the call parameters from WebKit types (which DRT uses) to WebCore types (which the mocks may use) ? If yes seems like we need wrappers to proxy the mock calls anyway on different platforms.. Cheers Satish On Thu, Jul 29, 2010 at 4:16 PM, Adam Barth aba...@webkit.org wrote: Thanks for bring this question to the list. I don't have a strong opinion here, but I want to make sure we think project-wide and pick something scalable. This discussion is also related to the discussion about adding something like a layoutTestController object to WebCore. Plumbing this mock API all the way through WebKit for each port seems like a waste. If we had something like a WebCore::LayoutTestController, it would make a lot more sense to expose that functionality there. Adam On Wed, Jul 28, 2010 at 11:30 AM, Steve Block stevebl...@google.com wrote: I'm in the process of adding a mock client for DeviceOrientation, which will be used in DumpRenderTree to test the feature. In order to share the mock across platforms, I'd like to add the mock to WebCore/platform/mock. An interface to the mock will have to be exposed to the embedder through the platform's WebKit API, so that it can be configured by DRT, eg ... mWebView.getDeviceOrientationClientMock().setOrientation(...); To avoid each platform having to produce it's own WebKit wrapper for the mock, I'm considering adding a common WebKit wrapper, perhaps to WebKit/common, and I wanted to get some feedback on the idea. The mock would be shared between all C++ WebKit platforms. (Note that this is for convenience only, a platform could equally use it's own WebKit wrapper around the WebCore mock (eg Mac may do so in ObjectiveC), or use its own mock altogether.) Of course we also need WebKit wrappers for all of the non-POD types used by the mock's interface, and these have to be common between all platforms. One obvious potential difficulty is the wrapper for WebCore::String. Each platforms already has a wrapper for this type, but there's no guarantee of interoperability, so we'd need to write a new common interface if we're to use the string type. If a wrapper for string ends up being too problematic, the approach could still be used for mocks that don't need the string type (of which DeviceOrientation is one), but the approach then seems less compelling. Do people think that this is a reasonable proposal and worth pursuing? Has there been any attempt to do anything similar before? Or is any attempt to write this kind of common WebKit code not worth the effort and destined to failure? You can see the work in progress for DeviceOrientation at https://bugs.webkit.org/show_bug.cgi?id=39589 and a similar patch for SpeechInput mocks at https://bugs.webkit.org/show_bug.cgi?id=42603 I'd appreciate any feedback you may have. Thanks, Steve -- Google UK Limited Registered Office: Belgrave House, 76 Buckingham Palace Road, London SW1W 9TQ Registered in England Number: 3977902 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] focusin/focusout events
On Tue, Jul 27, 2010 at 10:37 AM, Darin Adler da...@apple.com wrote: This sequence doesn’t sound too terrible to me. But I don’t fully understand the proposal. At the time the focusin event fires we won’t yet know what item is getting focus? I think we do know this and it wouldn't be too hard to implement. It's just a question of what we think the best behavior is. Specifically, in Document::setFocusedNode, we know both the new focused node and the old focused node when firing these events. The “we” I meant is the JavaScript code on the webpage. I see. I hadn't thought about this part. As per the current state of the DOM 3 spec for the target/relatedTarget event object: target relatedTarget blur/DOMFocusOut element losing focus element losing focus focus/DOMFocusIn element receiving focus element receiving focus focusin element receiving focus element losing focus focusout element losing focus element receiving focus The spec looks reasonable to me and I think we could implement it without worry about web compatibility since we would only be modifying the focusin/focusout events, which we just added recently. The only thing I'd like to change in the spec is that focusin/focusout are not cancelable, but that's a whole separate issue and something that should be addressed on www-dom first. Anyone object to that? Specifically, the proposal is to change our event order to match the spec: http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#events-focusevent-event-orderand to change the focusin/focusout events to have target/relatedTarget values as above. Ojan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Enabling the HTML5 tree builder soon
No change in iBench. -- Stephanie On Jul 28, 2010, at 8:15 PM, Stephanie Lewis wrote: I believe it is somewhere, but the setup is a hassle, so I'll run it tomorrow for you. -- Stephanie On Jul 28, 2010, at 8:13 PM, Adam Barth wrote: On Wed, Jul 28, 2010 at 7:39 AM, Maciej Stachowiak m...@apple.com wrote: On Jul 27, 2010, at 9:06 PM, Stephanie Lewis wrote: I measure it as a 1% win on the PLT. Might be a good idea to test HTML iBench as well. Sure. I'd be happy to. Is that benchmark available publicly? Adam ___ 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
