New issue
Advanced search Search tips
Note: Color blocks (like █ or █) mean that a user may not be available. Tooltip shows the reason.

Issue 681519 link

Starred by 1 user
Status: Assigned
Owner:
changwan@chromium.org
Cc:
█ aelias@chromium.org
yosin@chromium.org
changwan@chromium.org
editing-dev@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 3
Type: Bug



Sign in to add a comment

Composition and/or DOM change should be notified to the browser

Project Member Reported by changwan@chromium.org, Jan 16 2017 
This was pointed out in code review: https://codereview.chromium.org/2370663002/.

There may be cases where composition and DOM changes should be notified to the browser, by cancelling composition or updating IME app's internal state. If the composition/DOM change accompanies selection change, it will notify the browser process, so those cases should be ruled out.

Example:

Composition [abc] becomes [aBc] by replacing nodeValue of the text node in the middle.

(Not sure if we need to update DOM change outside composition as well.. yosin@, could you add your thought?)

But there may still be some conflict if there was further composition update from browser process, so we should be careful.

Issue 650204 mentions a similar synchronization problem although not same.

As for the mechanism to detect DOM change from InputMethodController, yosin@ mentioned
SynchronousMutationObserver (https://chromium.googlesource.com/chromium/src/+/master/third_party/WebKit/Source/core/dom/SynchronousMutationObserver.h)

Comment 1 by yosin@chromium.org, Jan 17 2017 

>Not sure if we need to update DOM change outside composition as well.. yosin@, could you add your thought?

Below cases can user surprised:
 1 Move the element enclosing composition to different place.
 2 Remove the element enclosing composition
 2 Hide the element enclosing composition; this is the similar to #1, but it is done by CSS change.

What we can do of them:
 1 Ignore. User can still enter the text. This is the intention of page author somehow.
 2 Cancel composition, since user can not enter the text.
 3 Cancel composition, same as #2.

We can handle DOM mutation by Synchronous Mutation Observer. For CSS change, we can detect in rendering pipeline after StyleClean. So, we need to plumbing in the pipeline as same as selection.

Comment 2 by aelias@chromium.org, Jan 17 2017 

> 2 Remove the element enclosing composition
> 3 Hide the element enclosing composition; this is the similar to #1, but it is done by CSS change.

These both ought to cause the textbox to get unfocused, which should set off a cascade of browser notifications as natural side effects.  According to my reading of http://w3c.github.io/html/editing.html#focus-fixup-rule-one , this should already be the case: "When the designated focused area of a control group is removed from that control group in some way (e.g., it stops being a focusable area, it is removed from the DOM, it becomes expressly inert, etc) [...]"
►

Sign in to add a comment