279246 - Implement 'ime-mode' property (WinIE CSS)

Status: RESOLVED FIXED

(Core :: Internationalization, enhancement)

Description

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Implement ime-mode property.
That is Win IE's CSS, not standard.
But Japanese people need this function.
(It was in demand, MS created this propery.)

I think this property's spec is following.

'ime-mode' property.

Value: auto | active | inactive | enabled | disabled
Initial: auto
Applies to: text input element(e.g., input[type=text], input[type=password] and
textarea.)
Inherited: yes
Percentages: N/A
Media: interactive
Computed value: specified value

auto
  UA dependent. If the element is password field, UA may care as 'disable'.
  Otherwise, UA may care as 'enabled'.

active
  UA should activate IME after the element got focus, immediately.

inactive
  UA should inactivate IME after the element got focus, immediately.
  But user can turn on IME.

enabled
  UA don't care for IME state. User can turn on IME.

disabled
  UA must inactivate IME after the element got focus, immediately.
  And user can *not* turn on IME.

If a user hopes that want to use IME on password field,
a user can add following rules for user style sheet.

input[type=password] {
  ime-mode: enabled;
}

Comment 1

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

See MSDN document.
http://msdn.microsoft.com/workshop/author/dhtml/reference/properties/imemode.asp

Comment 2

[Boris Zbarsky [:bzbarsky]]

So how does this help the user, exactly?

Comment 3

[Jungshik Shin]

It's relatively rare that non-ASCII characters are used for password, but IME
users often forget to deactivate it when entering password, which leads to a
password mismatch. So, it'd be handy if the author of a web page can control it
knowing whether non-ASCII characters are allowed or not for password (or some
other input fields). However, it's not clear if just controlling IME status (for
CJK users) is sufficient. What about Russian, Greek, Indian, Hebrew, Arabic users? 

  

Comment 4

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

(In reply to comment #2)
> So how does this help the user, exactly?

If the user uses the form repeatedly, many people want to be changed IME state
automatically. Because people think that it is troublesome.
But it is not good way for grobal web pages. for intranet applications.

Comment 5

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

(In reply to comment #3)
> However, it's not clear if just controlling IME status (for
> CJK users) is sufficient. What about Russian, Greek, Indian, Hebrew, Arabic
users?    

I think that for CJK users need this property.
Because they use IME.
But Russian, Greek, Indian, Hebrew, Arabic users are not using IME.
They can use inputmode attribute in XForms and WebForms.
But CJK users are not enough if we can use only inputmode attribute.

Comment 6

[Jungshik Shin]

(In reply to comment #5)

> I think that for CJK users need this property.
> Because they use IME.

I didn't have any doubt about the need (see comment #3) to control the 'input
mode' for CJK users as well as non-CJK users. However, whether implementing
'ime-mode' CSS property is  the best is another matter. Practically, it appears
so, but ......

> But Russian, Greek, Indian, Hebrew, Arabic users are not using IME.
> They can use inputmode attribute in XForms and WebForms.

Some Indic script users prefer to use an IME although they can do without it. On
the other hand, Koreans can do without an IME depending on the situation. Well,
that's a digression.  

Anyway, thanks for the info. about 'inputmode' in Xforms and WebForms, which
makes me less convinced about the need to implement 'yet-non-standard'
'ime-mode'. I know well that they cover a little different grounds and that
'ime-mode' is still useful. However, it seems possible to 'tweak' 'inputmode' to
cover what's covered by 'ime-mode'.  

[1] http://www.w3.org/TR/xforms/sliceE.html
[2] 
http://www.whatwg.org/specs/web-forms/2004-12-10-call-for-comments/#the-inputmode

Comment 7

[Hixie (not reading bugmail)]

Could you let me know how inputmode should be tweaked so that I can update the
Web Forms 2.0 spec? I really don't understand this well enough to know what
features inputmode lacks that it needs.

Comment 8

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

I think inputmode attribute is not related ime-mode.
We need simple function that is controller of IME state.
E.g., inputmode attribute cannot express "ime-mode: inactive;".

Comment 9

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

I think ime-mode property should not be used in "global" web pages.
Because it reduces usability and not web standard property.

Therefore, if we implement this property, we should not enable the property on
default settings.

Comment 10

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Attachment: testcase

Comment 11

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Attachment: Patch rv1.0

This works on Windows only. Because we are working to implement IME API on other plattforms, now. But for the test of implementation, we need this extra CSS. And if we implemnt this, we can make more usability on our products, e.g., on the History tab on Fx Option dialog, the editor needs numeric only. We will disable IME on this editor, we don't need to control IME state myself.

Comment 12

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

> Therefore, if we implement this property, we should not enable the property on
> default settings.

I cancel this comment. We need this property for controlling on chrome.

Comment 13

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

I have better comment for the reason why we need to implement this.

'inputmode' attribute in Xforms and WebForms specifies the filtering for input string, right?

'ime-mode' property doesn't filter the input string. (Note that if "ime-mode: disabled;", we cannot input CJK characters directly. However, we can input the characters by "paste".) This property helps the user by automatically IME state controlling. Of course, this might confuse the user if it is used on global web sites. But on intranet application, this is needed. E.g., on the telephone number input field, IME is not needed. If the user uses it repeatedly, the user might hope that the IME should be disabled automatically.

Comment 14

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Do you have tests that show this is compatible with what WinIE implements?

Is the specification in comment 0 compatible with the MSDN documentation (URL?) and what WinIE implements?
Why is it implemented on Windows only?  If it's not difficult to implement on other platforms, it should be.  If it is, why is it difficult?

Comment 15

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

(In reply to comment #14)
> Do you have tests that show this is compatible with what WinIE implements?
My patch can also control IME state on password editor.
# IE support these properties on non-password editor.
# E.g., input[type=text] and textarea elements.

This part is only difficult from WinIE.

> Is the specification in comment 0 compatible with the MSDN documentation (URL?)
> and what WinIE implements?
Yes. But only above case is different from WinIE.

> Why is it implemented on Windows only?  If it's not difficult to implement on
> other platforms, it should be.  If it is, why is it difficult?
For IME state controling, we need to implement nsIKBStateControl on nsWindow or nsWidget. But we cannot finish the works for nsIKBStateControl on other platforms, now. I think we'll be able to implement the nsIKBStateControl methods on Mac(Carbon) and GTK2. (But I don't know we can implement open state controller that is used by "-moz-ime-mode: active;" and "-moz-ime-mode: inactive;". If we cannot implement it, we may process these values as 'enabled' on the platform.)

So, it is difficult works. Because on UNIX and Linux, we don't have standardized spec for IME. E.g., on GTK2, I think the applications cannot control IME open state. Because these APIs for IME are not existing. On Mac(Carbon), we may implement perfectly. Because Mac's Flash Player can control IME state. On Mac(Cocoa), maybe, we cannot implement these methods. Because Cocoa doesn't have IME controlling APIs...

Comment 16

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Oops... Sorry.
> This part is only difficult from WinIE.
                    ^^^^^^^^^
It's *different*.

Comment 17

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

I tested on WinIE6 SP2. But the CSS values are not inherited on IE. The MSDN document and actual behavior are different...(MSDN said, "The Cascading Style Sheets (CSS) attribute is inherited.") But this property should inherit from parent.

Comment 18

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Should it inherit?  The concept of being editable doesn't inherit.

Also, it seems like not applying it to password controls makes sense.  If a user can't see what is being typed, perhaps it's best if what happens is consistent.  It also seems unlikely that the page will know more about what types of characters the user puts in his password than the user does.

Comment 19

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

(In reply to comment #18)
> It also seems unlikely that the page will know more about what
> types of characters the user puts in his password than the user does.

That may not be true, but the first part still stands.

Comment 20

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Current Gecko(without on Win32), Opera and Konqueror can use IME on password field.(Note that this behavior is not usable. But they can use IME.)
Only Gecko(Trunk) of Win32 and WinIE cannot use IME on password field.(Note that we can post CJK characters by paste to password field.)

So, the password field behavior depends on UA.

> Should it inherit?

I think that this property is more useable if it inerits. E.g., if an XBL component has some editors, and the author wants to disable IME on the all editors, if it iherits, we need only following style rule.

anXBLCompName {
  -moz-ime-mode: disable;
}

But if it doesn't inherit, we need following style rule.
anXBLCompName *{
  -moz-ime-mode: disable;
}

I think that the asterisk is redundant.

And antoher case, if the form of web page has following content:
<p class="tel">
  <input type="text"> - <input type="text"> - <input type="text">
</p>
We can use following style for this content.
p.tel{
  -moz-ime-mode: disable;
}

Are these cases unnatural?

Comment 21

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

I'm still inclined towards thinking it should not be inherited by default, but I really need to do some testing to figure that out -- something that would probably take me a good bit of time, so it's delaying this review.

But something else to think about:  if we add mechanisms for making arbitrary elements user-editable, would you really want the ime-mode to be controlled per-element rather than per-editor?  If it's not inherited, then it makes sense to use the mode on the element that establishes the editor.  But if it's inherited, it would make sense to use the mode on each element within the editor, which seems ugly.

Comment 22

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

> But if it's
> inherited, it would make sense to use the mode on each element within the
> editor, which seems ugly.

Umm... you are right. I agree this. I'll attach non-inheriting patch.

# FYI: I'm working on GTK2 implementation in bug 321468. By the GTK2 spec,
# 'active' and 'inactive' will work as 'enabled' on GTK2 build.
# But 'auto', 'enabled' and 'disabled' works fine :-)

Comment 23

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Attachment: testcase2

Comment 24

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Attachment: Patch rv2.0

This is non-inherit version.

Comment 25

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

It seems I didn't ask this earlier; I think I meant to as followup to my earlier questions, but forgot:

So if WinIE implements this as 'ime-mode', and this is basically compatible, why should we use the '-moz-' prefix?  The purpose of using vendor prefixes is to prevent the spec from being constrained by prior implementation, but that's already the case here.  So aren't we better off being compatible with WinIE?

Also, when you change nsIDOMNSCSS2Properties, you should:
 1. add to the end of the interface
 2. bump the IID

+  if (eCSSUnit_Auto == uiData.mIMEMode.GetUnit()) {

You should also check for eCSSUnit_Initial here.

+  // ignore mIMEMode

Wouldn't a FRAMECHANGE hint make dynamic changes work correctly?

Is there somebody more knowledgable about editor and IME who could review the nsEditor.cpp changes?  smontagu?

Comment 26

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Also, I don't think the name of the value you're adding, 'enabled', makes much sense.  (Am I correct that this value is not implemented by WinIE, but you're adding it because you're adding password field support?)  It seems more like you want that new value to be called 'normal' or something else that doesn't suggest that a change will take place.

Also, I'm a bit concerned that both jshin and Hixie seem to think this shouldn't happen.  Is that still the case?

Comment 27

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

dbaron:

Thank you for your review.

(In reply to comment #25)
> So if WinIE implements this as 'ime-mode', and this is basically compatible,
> why should we use the '-moz-' prefix?  The purpose of using vendor prefixes is
> to prevent the spec from being constrained by prior implementation, but that's
> already the case here.  So aren't we better off being compatible with WinIE?

I don't think so. We can keep 'perfect' compatible only on Windows. But on other environments, we cannot do it. And I and Mr. Makoto Murata (W3C XML WG) have discussed for IME controling way on XML. He said that we should not specify on standard specs. Because IME specs (e.g., what status applications can change.) depend on the OS, toolkit and platforms. Therefore, I think that this property should be implemented on each UA with each specs and each property name. So, I think that we should use '-moz-' prefix for Web App Developers.
# Note that this proeprty should not be used on *public* HTML document.
# But this property is usable for *private* Web Apps.

> +  // ignore mIMEMode
> 
> Wouldn't a FRAMECHANGE hint make dynamic changes work correctly?

I think that we don't need to dynamic change for this property. Because this property works only when the editor widget gets focus.

> Is there somebody more knowledgable about editor and IME who could review the
> nsEditor.cpp changes?  smontagu?

I think that timeless is good people.

(In reply to comment #26)
> Also, I don't think the name of the value you're adding, 'enabled', makes much
> sense.  (Am I correct that this value is not implemented by WinIE, but you're
> adding it because you're adding password field support?)  It seems more like
> you want that new value to be called 'normal' or something else that doesn't
> suggest that a change will take place.

I think that people may think "What is different from 'auto' and 'normal'?".
For Windows users, it is normal that the password field is IME disabled.
But 'enabled/normal' value changes the normal state for the people.
I think that 'normal' is not natural.

> Also, I'm a bit concerned that both jshin and Hixie seem to think this
> shouldn't happen.  Is that still the case?

I think that Hixie doesn't understand the importance of IME controling...
# And I cannot tell it to him, with my poor English...

And I think many IME users hate this property on public HTML documents. But if we implement by CSS, the users can override the style by User Style Sheet that thing is better than other ways(e.g., XML attribute).

Comment 28

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Attachment: Patch rv2.1

Updating following points:

> Also, when you change nsIDOMNSCSS2Properties, you should:
>  1. add to the end of the interface
>  2. bump the IID

> +  if (eCSSUnit_Auto == uiData.mIMEMode.GetUnit()) {
> 
> You should also check for eCSSUnit_Initial here.

Comment 29

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Attachment: Patch rv3.0

O.K. I change my mind. The '-moz-ime-mode' is disabled on web contents in default settings(but it's enabled on chrome). For intranet application, the organizations can enable the style on them environment.

I'm requesting to review to jshin. Jshin, what do you think?

Comment 30

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Attachment: Patch rv3.1

Comment 31

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

(In reply to comment #27)
> (In reply to comment #25)
> > So if WinIE implements this as 'ime-mode', and this is basically compatible,
> > why should we use the '-moz-' prefix?  The purpose of using vendor prefixes is
> > to prevent the spec from being constrained by prior implementation, but that's
> > already the case here.  So aren't we better off being compatible with WinIE?
> 
> I don't think so. We can keep 'perfect' compatible only on Windows. But on
> other environments, we cannot do it. And I and Mr. Makoto Murata (W3C XML WG)
> have discussed for IME controling way on XML. He said that we should not
> specify on standard specs. Because IME specs (e.g., what status applications
> can change.) depend on the OS, toolkit and platforms. Therefore, I think that
> this property should be implemented on each UA with each specs and each
> property name. So, I think that we should use '-moz-' prefix for Web App
> Developers.

I don't understand this argument.  You say the reason for being different from IE is that -moz-ime-mode will be different between platforms.   But that seems to be a reason for making the property name different between platforms rather than a reason for making it different from IE's name.

But I don't think property names should be different between platforms because of platform differences.  Instead, the property values should be general enough that they make sense in the environment provided by each platform (although on some platforms some of the values may always be treated the same way).

Comment 32

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

(In reply to comment #31)
> But I don't think property names should be different between platforms because
> of platform differences.  Instead, the property values should be general enough
> that they make sense in the environment provided by each platform (although on
> some platforms some of the values may always be treated the same way).

Right. But I have a worry still now.

Should we use vendor prefix for CSS2.1 4.1.2.1?
http://www.w3.org/TR/CSS21/syndata.html#q4
If you think this is no problem, I will remove the prefix in next patch. I don't have more reason for the issue.

Comment 33

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

The reason for vendor prefixes is to prevent the namespace of CSS properties from being used up.  That is, it is to prevent vendors from using names that a future specification might want to use.  However, IE has *already* used this name.  So there's no additional harm to us using it.

Comment 34

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

(In reply to comment #33)
> The reason for vendor prefixes is to prevent the namespace of CSS properties
> from being used up.  That is, it is to prevent vendors from using names that a
> future specification might want to use.  However, IE has *already* used this
> name.  So there's no additional harm to us using it.

O.K. I'll remove the prefix tomorrow.

Comment 35

[Jungshik Shin]

Comment on attachment 219023 [details] [diff] [review]
Patch rv3.1

Sorry for the delay. More  importantly,
I'm sorry I don't have enough time to review this patch properly, but I, now, am taking back my initial reluctance/objection so that you can go ahead if you find another reviewer and dbaron's sr.

Comment 36

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

(In reply to comment #35)
> my initial reluctance/objection

The current patch does not enable the ime-mode property in default settings with Web pages. I think that your discontent is obsoleted now.
# the style can be used by only people who needs the style effect.

Comment 37

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Attachment: Patch rv3.2

Removing the prefix. dbaron, jshin cannot review now. Do you want more reviewers?
# I think that the patch needs the review from timeless for the editor part. But it should request after dbaron's review.

Comment 38

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Attachment: testcase3 (for without prefix)

Comment 39

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Sorry for not getting to this for so long.

I don't think we want a pref here -- at least not one implemented in C++ this way.  If we need a pref, it should be done using !important rules in a user style sheet.

But I think the reason to be implementing something like this is because we think it's good to implement, in which case we should turn it on.  I think turning it on may well be reasonable; especially given that it should be compatible with something IE does -- although if we change our minds later it may be sending a bad message to authors if we later disable it.  But hopefully authors will be reasonable.

In nsIDOMCSS2Properties.idl, you should bump the IID of the interface you're changing, not the IID of the frozen interface earlier in the file.

I think the computed style changes need some merging.


I remember a bunch of discussion about this in the past, but what's the state, in the current patch, of how the values you're adding differ from what IE/Windows supports?  I recall you're adding an additional value that does something different for passwords, I think.  Is that still part of the patch?

Have you tested that the property is also a non-inherited property in IE?

Comment 40

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

(In reply to comment #39)
> I don't think we want a pref here -- at least not one implemented in C++ this
> way.  If we need a pref, it should be done using !important rules in a user
> style sheet.
> 
> But I think the reason to be implementing something like this is because we
> think it's good to implement, in which case we should turn it on.  I think
> turning it on may well be reasonable; especially given that it should be
> compatible with something IE does -- although if we change our minds later it
> may be sending a bad message to authors if we later disable it.  But hopefully
> authors will be reasonable.

O.K. I'll change to turn on it in default. If users want to disable it, they should use user style sheet.

> In nsIDOMCSS2Properties.idl, you should bump the IID of the interface you're
> changing, not the IID of the frozen interface earlier in the file.

Wow, thank you for the point.

> I remember a bunch of discussion about this in the past, but what's the state,
> in the current patch, of how the values you're adding differ from what
> IE/Windows supports?  I recall you're adding an additional value that does
> something different for passwords, I think.  Is that still part of the patch?

Yes. I still think that we should add new value. But I changed my mind in current work on Mac. Your suggestion that is 'enabled' should be 'normal' is good. On Mac, the IMEs are a part of Keyboard layouts. I.e., if IME is disabled by ime-mode, the users cannot use non-roman keyboard layouts (e.g., Cyrillic and Russian keyboard layouts). So some users may hate this behavior (this is MacOS X's default behavior, but Apple agree that there are people who hates the approach). Therefore, I think that we should need the new value for the users can change the behavior in user style sheet. And for the Mac users, I think that the 'normal' is better name.

> Have you tested that the property is also a non-inherited property in IE?

yes. the descendant doesn't control the IME state. I have confirmed on IE6. And I retested on IE7, and I confirmed same behavior.

Comment 41

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Could you update the patch based on the above comments?

Also, I've now landed a large number of automated tests in layout/style/test/.  These should make it much easier for me to review the addition of new CSS properties, since they test most of the things that I need to check for.  However, when you add a new property you need to add information to property_database.js.  So, when you update the patch, could you:

1. add the appropriate lines to layout/style/test/property_database.js .  (initial_values are some example values that compute to the property's initial value; other_values are some example values that compute to other values; invalid_values are example values that should be rejected as syntactically incorrect)

2. run the tests and fix bugs needed to make them pass.  This is done by:
$ cd <objdir>/_tests/testing/mochitest/
$ perl ./runtests.pl
and then click on the directory name "layout/style/tests" in the list, and then click "Run tests" at the top of the page (to run all the tests shown on that page).  You can click on a test if failures (red) are shown.  The orange numbers are todos (known failures).

Comment 42

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Thank you. I'm busy now, therefore, I need a few days for the new patch. Please wait, thanks.

Comment 43

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Attachment: Patch rv4.0

Sorry for the delay.

This patch changes:
1. 'enabled' to 'normal'.
2. adding tests.
3. new format for nsComputedDOMStyle.

This patch clears the tests in layout/style.

Comment 44

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Attachment: testcase 4 (enabled -> normal)

Comment 45

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

(In reply to comment #25)
> Is there somebody more knowledgable about editor and IME who could review the
> nsEditor.cpp changes?  smontagu?

I have requested the reviews to timeless in other bugs which changes the nsEditor for IME.

Comment 46

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Or, roc is better, |nsEditor::GetPreferredIMEState| was created by roc's review.

Comment 47

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Comment on attachment 264848 [details] [diff] [review]
Patch rv4.0

>Index: layout/style/nsComputedDOMStyle.cpp
>+  if (uiData->mIMEMode != NS_STYLE_IME_MODE_AUTO) {
>+    if (uiData->mIMEMode == NS_STYLE_IME_MODE_NORMAL) {

>+    } else {

>+    }
>+  } else {

>+  }

It probably makes more sense to structure this as:

if (uiData->mIMEMode == NS_STYLE_IME_MODE_AUTO) {
} else if (uiData->mIMEMode == NS_STYLE_IME_MODE_NORMAL) {
} else {
}

And you should probably use nsCSSProps::ValueToKeywordEnum instead, which would allow you to pull the val->SetIdent() call outside of the branches, so it's just:

nsCSSKeyword keyword;
if (uiData->mIMEMode == NS_STYLE_IME_MODE_AUTO) {
  keyword = eCSSKeyword_auto;
} else if (uiData->mIMEMode == NS_STYLE_IME_MODE_NORMAL) {
  keyword = eCSSKeyword_normal;
} else {
  keyword = nsCSSProps::ValueToKeywordEnum(uiData->mIMEMode,
              nsCSSProps::kIMEModeKTable)
}
val->SetIdent(nsCSSKeywords::GetStringValue(keyword));

With that change, r+sr=dbaron.

Comment 48

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Attachment: Patch rv4.1 (for checking-in)

Thank you, dbaron!

Comment 49

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

checked-in.

the mac's testing is orange, but the count of failed is zero, what's this??
TUnit
250/0
reftest
557/0/59
mochitest
23151/0/2141
chrome
31/0/0

Comment 50

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

The mac testing tinderbox sometimes randomly goes orange (maybe it's a crash on shutdown).  Nothing to worry about.

Comment 51

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Thank you, the testing after it succeeded.

Comment 52

[Adam Guthrie]

Masayuki, it looks like this may have caused a small regression in Tp/Tp2 times on one of the Linux tinderboxes. Do you think this patch could've caused a slowdown in page load time?

Comment 53

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Adam:

I don't think that this patch caused the slowdown. This patch added a new property for CSS and it will run only when an editor gets the focus.

Comment 54

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Attachment: draft for document

sheppy:

I wrote the document as plain text.
What should I do for committing this to MDC?
# and I need the review of native speakers.

Comment 55

[Eric Shepherd [:sheppy]]

I've created an ime-mode article and integrated your content into it.  Please let me know if there are any problems:

http://developer.mozilla.org/en/docs/CSS:ime-mode

Comment 56

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Sheppy:

Thank you for your work!

I find a mistake. 'deactivated' of the value is not correct. It's 'disabled'.

Comment 57

[Eric Shepherd [:sheppy]]

I'll revise that if you haven't already.  It's listed as being called "deactivated" in the other ime-mode references on the web, so I presumed it was a typo in the document you wrote.  My mistake.

Comment 58

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Does that mean we're not matching IE here?  Should we be?

Comment 59

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

No, 'disabled' is correct.

See http://msdn2.microsoft.com/en-us/library/ms533883.aspx

"ime-mode: disabled;" works fine on WinIE7. (ime-mode: deactivated; doesn't work fine.)

Comment 60

[Kang-Hao (Kenny) Lu [:kennyluck]]

I sent a post about this property on www-style[1] just in case you want to make some comments. I have to say I still don't quite get the reason why we are having 'normal'. Or... why does 'ime-mode' need to apply to password field at all? Is that behavior Chrome-only or we need to support it on the Web?

FYI, WebKit people discussed about this property on webkit-dev[2] and decided not to land the patch[3] about supporting this property.

[1] http://lists.w3.org/Archives/Public/www-style/2012Feb/0759
[2] https://lists.webkit.org/pipermail/webkit-dev/2010-October/thread.html#14613
[3] https://bugs.webkit.org/show_bug.cgi?id=21279