CANCEL: Make "compositionstart" event cancelable

Make "compositionstart" event cancelable

This patch makes "compositionstart" event cancelable as DOM Level 3 event
specification[1].

A cancellation of "compositionstart" results in a renderer->browser IPC
(ViewHostMsg_ImeCancelComposition), and each platform-dependent RWHV
implementation is
responsible for handling it.

[1] http://www.w3.org/TR/DOM-Level-3-Events/#events-compositionevents
BUG=228440
TEST=Source/core/editing/InputMethodControllerTest.cpp

[yosin_UTC9, 2014-06-06 01:29:28]

Could you review this patch?
Thanks in advance.

[Yuta Kitamura, 2014-06-06 02:16:30]

According to
<https://developer.mozilla.org/en-US/docs/DOM/DOM_event_reference/compositions...>,
this event is not cancelable in Gecko.

The following statement from the MDN looks worrysome:

> Gecko fires this event when IME starts composition, and
> some platforms don't have an API for canceling composition 
> once it's begun. In addition, Gecko can't know whether a
> keyboard event will start composition or not until IME
> actually starts composition. Because of this,
> event.preventDefault() doesn't work on compositionstart
> events in Gecko.

Does this concerm apply to Blink?

[kochi, 2014-06-06 02:25:08]

On 2014/06/06 02:16:30, Yuta Kitamura wrote:
> According to
>
<https://developer.mozilla.org/en-US/docs/DOM/DOM_event_reference/compositions...>,
> this event is not cancelable in Gecko.
> 
> The following statement from the MDN looks worrysome:
> 
> > Gecko fires this event when IME starts composition, and
> > some platforms don't have an API for canceling composition 
> > once it's begun. In addition, Gecko can't know whether a
> > keyboard event will start composition or not until IME
> > actually starts composition. Because of this,
> > event.preventDefault() doesn't work on compositionstart
> > events in Gecko.
> 
> Does this concerm apply to Blink?

Just ignoring composition updates from IME will make the state between
Blink and IME inconsistent.

For example, Blink can just ignore composition update, but IME still
maintain its state (composition text and other related information).
There is no ACK mechanism that IME can confirm that its update is
accepted by editor etc.

We should make what "cancel" mean and how cancellation should behave first,
before doing implementation.

[kochi, 2014-06-06 05:19:41]

On 2014/06/06 02:25:08, Takayoshi Kochi wrote:
> On 2014/06/06 02:16:30, Yuta Kitamura wrote:
> > According to
> >
>
<https://developer.mozilla.org/en-US/docs/DOM/DOM_event_reference/compositions...>,
> > this event is not cancelable in Gecko.
> > 
> > The following statement from the MDN looks worrysome:
> > 
> > > Gecko fires this event when IME starts composition, and
> > > some platforms don't have an API for canceling composition 
> > > once it's begun. In addition, Gecko can't know whether a
> > > keyboard event will start composition or not until IME
> > > actually starts composition. Because of this,
> > > event.preventDefault() doesn't work on compositionstart
> > > events in Gecko.
> > 
> > Does this concerm apply to Blink?
> 
> Just ignoring composition updates from IME will make the state between
> Blink and IME inconsistent.
> 
> For example, Blink can just ignore composition update, but IME still
> maintain its state (composition text and other related information).
> There is no ACK mechanism that IME can confirm that its update is
> accepted by editor etc.
> 
> We should make what "cancel" mean and how cancellation should behave first,
> before doing implementation.

According to the spec, cancellation differs from IME cancellation (close
the IME window or hit ESC key).  So the cancel here looks fine - just
cancelling the current composition session.

Once compositionstart event is canceled, accompanying compositionend event
has to be sent.

In the spec, titled "Canceling Composition Events"
> If the initial compositionstart event is canceled then the text composition
> session should be terminated. Regardless of whether or not the composition
> session is terminated, the compositionend event must be sent.

[kochi, 2014-06-06 05:20:41]

https://codereview.chromium.org/311053008/diff/20001/Source/core/editing/Inpu...
File Source/core/editing/InputMethodController.cpp (right):

https://codereview.chromium.org/311053008/diff/20001/Source/core/editing/Inpu...
Source/core/editing/InputMethodController.cpp:264: return;
You have to dispatch compositionend event for this case.

[yosin_UTC9, 2014-06-09 02:29:14]

On 2014/06/06 02:16:30, Yuta Kitamura wrote:
> According to
>
<https://developer.mozilla.org/en-US/docs/DOM/DOM_event_reference/compositions...>,
> this event is not cancelable in Gecko.
> 
> The following statement from the MDN looks worrysome:
> 
> > Gecko fires this event when IME starts composition, and
> > some platforms don't have an API for canceling composition 
> > once it's begun. In addition, Gecko can't know whether a
> > keyboard event will start composition or not until IME
> > actually starts composition. Because of this,
> > event.preventDefault() doesn't work on compositionstart
> > events in Gecko.
> 
> Does this concerm apply to Blink?

Blink implementation of "compositionstart" event dispatch doesn't relate to
keyboard event. It is dispatched by |InputMethodController::setComposition()|
when there is no |Node| for composition in DOM tree.

"compositionstart" isn't tight with keyboard. It can be fired speech recognizer,
hand writing and so on.

Note: IE's compositionstart is cancelable.

[Yuta Kitamura, 2014-06-09 02:48:42]

On 2014/06/09 02:29:14, yosi wrote:
> Blink implementation of "compositionstart" event dispatch doesn't relate to
> keyboard event. It is dispatched by |InputMethodController::setComposition()|
> when there is no |Node| for composition in DOM tree.
> 
> "compositionstart" isn't tight with keyboard. It can be fired speech
recognizer,
> hand writing and so on.

I don't understand how this explanation relates to the MDN notes.

Please provide enough context about this compatibility story
in the change description.

[yosin_UTC9, 2014-06-09 03:35:45]

PTAL

I update
 - change description what Blink and Chromium does at composition cancelation
 - dispatch "compositionend" event as the spec.

[kochi, 2014-06-09 04:02:34]

On 2014/06/09 03:35:45, yosi wrote:
> PTAL
> 
> I update
>  - change description what Blink and Chromium does at composition cancelation
>  - dispatch "compositionend" event as the spec.

I don't think the added paragraph ("In Blink, ~") in the description well
explains what this CL is.
If the intention was to explain the responsibility for cancelling the current
composition,
how about the following:

A cancellation of "compositionstart" results in a renderer->browser IPC
(ViewHostMsg_ImeCancelComposition), and each platform-dependent RWHV
implementation is
responsible for handling it.


I don't understand your reply to yutak as well, you don't explain why
it is okay to land this CL in blink side, while some platform may not be
able to implement the functionality.

Please add yukishiino@ and shuchen@ for comments/concerns about Linux/ChromeOS
implementations.

[yosin_UTC9, 2014-06-09 05:07:27]

On 2014/06/09 04:02:34, Takayoshi Kochi wrote:
> On 2014/06/09 03:35:45, yosi wrote:
> > PTAL
> > 
> > I update
> >  - change description what Blink and Chromium does at composition
cancelation
> >  - dispatch "compositionend" event as the spec.
> 
> I don't think the added paragraph ("In Blink, ~") in the description well
> explains what this CL is.
> If the intention was to explain the responsibility for cancelling the current
> composition,
> how about the following:
> 
> A cancellation of "compositionstart" results in a renderer->browser IPC
> (ViewHostMsg_ImeCancelComposition), and each platform-dependent RWHV
> implementation is
> responsible for handling it.
> 
> 
> I don't understand your reply to yutak as well, you don't explain why
> it is okay to land this CL in blink side, while some platform may not be
> able to implement the functionality.

According to the spec, actual behavior of composition cancelation depends on
platform, e.g. Linux doesn't have concept about composition cancelation. It
seems there is way to simulate composition cancelation like focus movement
during text composition.

> Please add yukishiino@ and shuchen@ for comments/concerns about Linux/ChromeOS
> implementations.

I updated CL description and added yukishiino@ and shuchen@ to reviewer.

yukishiino@ and shuchen@, please put comments/concerns about composition
cancelation on Linux/ChromeOS.

[yukawa, 2014-06-09 05:46:27]

On 2014/06/09 05:07:27, yosi wrote:
> On 2014/06/09 04:02:34, Takayoshi Kochi wrote:
> > On 2014/06/09 03:35:45, yosi wrote:
> > > PTAL
> > > 
> > > I update
> > >  - change description what Blink and Chromium does at composition
> cancelation
> > >  - dispatch "compositionend" event as the spec.
> > 
> > I don't think the added paragraph ("In Blink, ~") in the description well
> > explains what this CL is.
> > If the intention was to explain the responsibility for cancelling the
current
> > composition,
> > how about the following:
> > 
> > A cancellation of "compositionstart" results in a renderer->browser IPC
> > (ViewHostMsg_ImeCancelComposition), and each platform-dependent RWHV
> > implementation is
> > responsible for handling it.
> > 
> > 
> > I don't understand your reply to yutak as well, you don't explain why
> > it is okay to land this CL in blink side, while some platform may not be
> > able to implement the functionality.
> 
> According to the spec, actual behavior of composition cancelation depends on
> platform, e.g. Linux doesn't have concept about composition cancelation. It
> seems there is way to simulate composition cancelation like focus movement
> during text composition.
> 
> > Please add yukishiino@ and shuchen@ for comments/concerns about
Linux/ChromeOS
> > implementations.
> 
> I updated CL description and added yukishiino@ and shuchen@ to reviewer.
> 
> yukishiino@ and shuchen@, please put comments/concerns about composition
> cancelation on Linux/ChromeOS.

HMM, I'm not sure how this proposed ViewHostMsg_ImeCancelComposition resolves
the
original crbug.com/228440. (Is't on Android!)

Can we have a DesignDoc?  I guess there are a lot of potential issues to be
discussed.
- Platform API feasibility
- Chromium specific limitations due to asynchronous IPCs.
- Test plans.
- etc...

[yosin_UTC9, 2014-06-09 09:54:28]

On 2014/06/09 05:46:27, yukawa wrote:
> On 2014/06/09 05:07:27, yosi wrote:
> > On 2014/06/09 04:02:34, Takayoshi Kochi wrote:
> > > On 2014/06/09 03:35:45, yosi wrote:
> > > > PTAL
> > > > 
> > > > I update
> > > >  - change description what Blink and Chromium does at composition
> > cancelation
> > > >  - dispatch "compositionend" event as the spec.
> > > 
> > > I don't think the added paragraph ("In Blink, ~") in the description well
> > > explains what this CL is.
> > > If the intention was to explain the responsibility for cancelling the
> current
> > > composition,
> > > how about the following:
> > > 
> > > A cancellation of "compositionstart" results in a renderer->browser IPC
> > > (ViewHostMsg_ImeCancelComposition), and each platform-dependent RWHV
> > > implementation is
> > > responsible for handling it.
> > > 
> > > 
> > > I don't understand your reply to yutak as well, you don't explain why
> > > it is okay to land this CL in blink side, while some platform may not be
> > > able to implement the functionality.
> > 
> > According to the spec, actual behavior of composition cancelation depends on
> > platform, e.g. Linux doesn't have concept about composition cancelation. It
> > seems there is way to simulate composition cancelation like focus movement
> > during text composition.
> > 
> > > Please add yukishiino@ and shuchen@ for comments/concerns about
> Linux/ChromeOS
> > > implementations.
> > 
> > I updated CL description and added yukishiino@ and shuchen@ to reviewer.
> > 
> > yukishiino@ and shuchen@, please put comments/concerns about composition
> > cancelation on Linux/ChromeOS.
> 
> HMM, I'm not sure how this proposed ViewHostMsg_ImeCancelComposition resolves
> the
> original crbug.com/228440. (Is't on Android!)
> 
> Can we have a DesignDoc?  I guess there are a lot of potential issues to be
> discussed.
> - Platform API feasibility
> - Chromium specific limitations due to asynchronous IPCs.
> - Test plans.
> - etc...

This patch is for Blink side changes of making "compositionstart" cancelable.
"compositonend" event dispatch and Linu(http://crbug.com/382930) issue on
composition cancelation will be addressed by other patches. (Not sure about
ChromeOS at this time)

Here is design doc:
https://docs.google.com/a/chromium.org/document/d/138_d6VuMnAK2QELmdG-KtwAv7-...

Note: Blink editing team priority is implementing polyfill/C++ of
contentEditable=minimal. Implementing "compositionend" at cancellation will be
handled later.

[yosin_UTC9, 2014-06-12 09:03:02]

Thanks for reviewing.

After offline discussion with IME experts, I decide to cancel this patch and
implementing cancelation of "compositionstart", because:
- IME can be fall into race condition, e.g. displaying IME UI during Blink sends
composition cancelation via IPC.
- Linux IME doesn't have concept of IME cancellation
- Mozillar explicitly states they don't implement "compositionstart" cancelation
on FireFox.