[webkit-dev] Handling IME composition events
Hello all, I’m working on a Hangul(Korean alphabet) composition issue in WebKit. https://bugs.webkit.org/show_bug.cgi?id=40518 By the way, I noticed that WebKit based browsers are inconsistent with IME composition events. According to the W3C DOM Level 3 events(http://bit.ly/bM7YVQ), 1) A browser should fire compositionstart, compositionupdate, and compositionend event during a composition. 2) The textEvent event should be dispatched after a compositionend event if the composition has not been canceled. 3) While a composition session is active, keyboard events should not be dispatched to the DOM (i.e., the text composition system swallows the keyboard events), and only compositionupdate events may be dispatched to indicate the composition process. However, all ports of WebKit handle composition events in inconsistent ways. Even keyboard events are still dispatched to the DOM during a composition. Therefore, it is necessary to fix those problems as follows: 1) IME Composition events should be handled consistently in all ports of WebKit. 2) The textInput event should be dispatched after a compositionend event. 3) Keyboard events should not be dispatched during a composition. The following link shows an example of testing composition events with the major WebKit based browsers. https://bug-43020-attachments.webkit.org/attachment.cgi?id=62647 I was wondering what is a good example of handling composition events. In my opinion, the composition events should be dispatched as follows if we follow the W3C DOM Level3 events. For example, when we type ‘rksk’ for inputting ‘가나' using Korean IME, Type ‘r(ㄱ)’ 1. compositionstart 2. input Type ‘k(ㅏ) 3. compositionupdate 4. input Type ‘s(ㄴ)’ 5. compositionupdate 6. input Type ‘k(ㅏ)’ 7. compositionend (for 가) 8. textInput 9. input 10. compositionstart 11. input mouse press 12. compositionend (for 나) 13. textInput 14. input Currently, Firefox, Chrome, and Safari don’t handle composition events like this because they seem not to follow the W3C specification on IME composition events yet. So I filed a bug for this issue. https://bugs.webkit.org/show_bug.cgi?id=43020 I would be grateful if you could give me your opinion on this issue. Thanks, Joone ___ 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 Jul 28, 2010, at 8:45 AM, Joone Hur wrote: Hello all, I’m working on a Hangul(Korean alphabet) composition issue in WebKit. https://bugs.webkit.org/show_bug.cgi?id=40518 By the way, I noticed that WebKit based browsers are inconsistent with IME composition events. According to the W3C DOM Level 3 events(http://bit.ly/bM7YVQ), 1) A browser should fire compositionstart, compositionupdate, and compositionend event during a composition. 2) The textEvent event should be dispatched after a compositionend event if the composition has not been canceled. 3) While a composition session is active, keyboard events should not be dispatched to the DOM (i.e., the text composition system swallows the keyboard events), and only compositionupdate events may be dispatched to indicate the composition process. The DOM Level 3 event model for input composition does not match the requirements of actual web content. This is unfortunate, but will hopefully be fixed in future. However, all ports of WebKit handle composition events in inconsistent ways. Even keyboard events are still dispatched to the DOM during a composition. Therefore, it is necessary to fix those problems as follows: 1) IME Composition events should be handled consistently in all ports of WebKit. I'm not sure this can be achieved as it depends (to an extent) on the platform IME system, and the active IME -- different IMEs have completely different behaviours making consistent behaviour across multiple platforms is an exercise in futility. However if you're seeing different behaviour with the same IME on a single platform that's a bug. 2) The textInput event should be dispatched after a compositionend event. Unsure of the specifics of this. 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. --Oliver ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Sharing WebKit mocks across platforms
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 Wed, Jul 28, 2010 at 11:13 AM, Oliver Hunt oli...@apple.com wrote: On Jul 28, 2010, at 8:45 AM, Joone Hur wrote: 2) The textInput event should be dispatched after a compositionend event. Unsure of the specifics of this. There's a discussion on www-...@w3.org about changing the spec here. See http://lists.w3.org/Archives/Public/www-dom/2010AprJun/0048.html. ___ 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
Awesome. Thanks. Adam On Wed, Jul 28, 2010 at 6:06 AM, Stephanie Lewis sle...@apple.com wrote: I measure it as a 1% win on the PLT. -- Stephanie On Jul 26, 2010, at 12:36 PM, Stephanie Lewis wrote: I can do this. -- Stephanie Lewis On Jul 26, 2010, at 5:57 AM, Adam Barth wrote: Would someone from Apple be willing to run the patch below though the PLT? We're doing well on our parsing benchmark (4% speedup), but the PLT might have a different mix of HTML. Thanks, Adam diff --git a/WebCore/html/HTMLTreeBuilder.cpp b/WebCore/html/HTMLTreeBuilder.cpp index 7a9c295..5b89c37 100644 --- a/WebCore/html/HTMLTreeBuilder.cpp +++ b/WebCore/html/HTMLTreeBuilder.cpp @@ -327,7 +327,7 @@ HTMLTreeBuilder::HTMLTreeBuilder(HTMLTokenizer* tokenizer, HTMLDocument* documen , m_originalInsertionMode(InitialMode) , m_secondaryInsertionMode(InitialMode) , m_tokenizer(tokenizer) - , m_legacyTreeBuilder(shouldUseLegacyTreeBuilder(document) ? new LegacyHTMLTreeBuilder(document, reportErrors) : 0) + , m_legacyTreeBuilder(0) , m_lastScriptElementStartLine(uninitializedLineNumberValue) , m_scriptToProcessStartLine(uninitializedLineNumberValue) , m_fragmentScriptingPermission(FragmentScriptingAllowed) On Thu, Jul 22, 2010 at 3:30 AM, Adam Barth aba...@webkit.org wrote: We're getting close to enabling the HTML5 tree builder on trunk. Once we do that, we'll have the core of the HTML5 parsing algorithm turned on, including SVG-in-HTML. There are still a bunch of details left to finish (such as fragment parsing, MathML entities, and better error reporting), but this marks a significant milestone for this work. The tree builder is markedly more complicated than the tokenizer, and I'm sure we're going to have some bad regressions. I'd like to ask your patience and your help to spot and triage these regressions. We've gotten about as much mileage as we can out of the HTML5lib test suite and the LayoutTests. The next step for is to see how the algorithm works in the real world. There are about 84 tests that will require new expectations, mostly due to invisible differences in render tree dumps (e.g., one more or fewer 0x0 render text). In about half the cases, we've manually verified that our new results agree with the Firefox nightly builds, which is great from a compliance and interoperability point of view. The other half involve things like the exact text for the isindex, which we've chosen to match the spec exactly, or the keygen element, which needs some shadow DOM love to hide its implementation details from web content. As for performance, last time we ran our parser benchmark, the new tree builder was 1% faster than the old tree builder. There's still a bunch of low-hanging performance work we can do, such as atomizing strings and inlining functions. If you're interested in performance, let me or Eric know and we can point you in the right direction. I don't have an exact timeline for when we're going to throw the switch, but sometime in the next few days. If you'd like us to hold off for any reason, please let Eric or me know. Adam P.S., you can follow along by CCing yourself on the master bug, https://bugs.webkit.org/show_bug.cgi?id=41123, or by looking at our LayoutTest failure triage spreadsheet, https://spreadsheets.google.com/ccc?key=0AlC4tS7Ao1fIdEo0SFdLaVpiclBHMVNQcHlTenV5TEEhl=en. ___ 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] Enabling the HTML5 tree builder soon
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] Enabling the HTML5 tree builder soon
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] Enabling the HTML5 tree builder soon
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
