This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 22194 - Clarificaiton of 'enabled' property behavior
Summary: Clarificaiton of 'enabled' property behavior
Status: RESOLVED FIXED
Alias: None
Product: WebAppsWG
Classification: Unclassified
Component: HISTORICAL - IME API (show other bugs)
Version: unspecified
Hardware: All All
: P2 normal
Target Milestone: ---
Assignee: Takayoshi Kochi
QA Contact: public-webapps-bugzilla
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-05-29 06:47 UTC by Takayoshi Kochi
Modified: 2013-07-04 07:42 UTC (History)
5 users (show)

See Also:


Attachments

Description Takayoshi Kochi 2013-05-29 06:47:43 UTC
Even though the spec assumes that the 'enabled' property associated with
the context can be used to detect whether the IME is turned on or not,
but for some cases it may not work as intended.

On Chromium (and possibly other browsers) a real IME context is shared in a
browser, and the state of the IME may change on focus change.

To illustrate this, if a page has one input field which has focus and
IME is turned on, context.enabled is expected to return true.
But once outside of the input field is clicked, the browser turns off IME.
A naive implementation of .enabled property will return false in that case,
but the state of IME will be restored when the input field gets focus again,
and .enabled returns true.

Webapps developers may assume that the state won't change on focus change.

Possible solutions:

1. Do not change the spec.

Users of the API will accept the behavior as is and let the behavior
implementation dependent.

2. Hold the .enabled state within context and restore when it gets focus

Retain the state and change the state only when the field has focus,
and once it loses focus and gets focus again, then restore the state.

This may be an expected behavior of most developers.

3. Remove .enabled from the spec

As .enabled may not be implemented on Mac/Android, it may be a good
idea to abandon .enabled and focus on having 'inputmode' attribute.
Microsoft's proposal also dropped .enabled (for the reason that
it won't support the case for non-editable element, though).

4. none of the above

Any other ideas?
Comment 1 Takayoshi Kochi 2013-07-04 07:42:29 UTC
I'll choose 3, abondoning .enable property.

Something like input type= or inputmode should be used instead to give hint to
user agent.