Re: [w3c/editing] EditContext: Do IME see the plaintext in `EditContext`? (#342)

One difficult thing of storing character bounds is, which rects of characters should be stored. As you know, the main process of a browser interacts with native IME, but layout information (in this case, `EditContext`) is in a remote process). So for making their communication asynchronous, layout information is cached in the main process before native IME retrieves character rects.

E.g., [Gecko caches the following character rects in the main process](https://searchfox.org/mozilla-central/rev/b847c844adf49013067281d3237e7ada24325a34/widget/ContentCache.cpp#293):
* All characters' rects in composition string if in a composition (required for showing candidate list window, some IME may show it at start of composition string, some other IME may show it at start of selected clause in composition string, etc)
* The first character rect in the editor (if there is no text, stores the caret rect for inserting first character)
* Before/after character rects of anchor/focus point of `Selection` (This is required for allowing IME to show tooltip like UI around selection)
* All characters' rects at last commit string only immediately after composition ends (this is required for Kakutei-undo feature of Japanese IMEs)

Once those requirements from browser is defined in the spec, web apps may be able to compute the character rects with simpler code (or they can put the layout information actively). And if the text position is changed by scroll in the view, those information need to be updated. So this issue may cause performance issue if web apps computes the rects too much or too strictly.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/editing/issues/342#issuecomment-938278894