Implement 'ime-mode' property (WinIE CSS)

RESOLVED FIXED in mozilla1.9alpha5

Status

()

--
enhancement
RESOLVED FIXED
14 years ago
7 years ago

People

(Reporter: masayuki, Assigned: masayuki)

Tracking

(5 keywords)

Trunk
mozilla1.9alpha5
css-moz, dev-doc-complete, inputmethod, intl, jp-critical
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite ?

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(3 attachments, 10 obsolete attachments)

2.10 KB, text/html
Details
24.77 KB, patch
Details | Diff | Splinter Review
3.46 KB, text/plain
Details
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;
}
Summary: Implement ime-mode property(WinIE's CSS) → Implement ime-mode property (WinIE's CSS)
So how does this help the user, exactly?

Comment 3

14 years ago
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? 

  
(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.
(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

14 years ago
(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
(Assignee)

Updated

14 years ago
Depends on: 276727
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.
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;".
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.

Updated

14 years ago
Blocks: 164421
(Assignee)

Updated

13 years ago
Depends on: 55751, 113187
(Assignee)

Updated

13 years ago
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.9alpha
Created attachment 204447 [details] [diff] [review]
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.
Attachment #204447 - Flags: superreview?
Attachment #204447 - Flags: review?
(Assignee)

Updated

13 years ago
Attachment #204447 - Flags: superreview?(dbaron)
Attachment #204447 - Flags: superreview?
Attachment #204447 - Flags: review?(dbaron)
Attachment #204447 - Flags: review?
> 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.
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.
(Assignee)

Updated

13 years ago
Summary: Implement ime-mode property (WinIE's CSS) → Implement '-moz-ime-mode' property (compatible property of WinIE's 'ime-mode')
(Assignee)

Updated

13 years ago
Keywords: css-moz
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?
(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...
Oops... Sorry.
> This part is only difficult from WinIE.
                    ^^^^^^^^^
It's *different*.
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.
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.
(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.
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?
(Assignee)

Updated

13 years ago
Depends on: 321468
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.
> 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 :-)
Created attachment 209700 [details] [diff] [review]
Patch rv2.0

This is non-inherit version.
Attachment #204447 - Attachment is obsolete: true
Attachment #209700 - Flags: superreview?(dbaron)
Attachment #209700 - Flags: review?(dbaron)
Attachment #204447 - Flags: superreview?(dbaron)
Attachment #204447 - Flags: review?(dbaron)
(Assignee)

Updated

13 years ago
Keywords: jp-critical
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?
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?
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).
Created attachment 215146 [details] [diff] [review]
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.
Attachment #209700 - Attachment is obsolete: true
Attachment #215146 - Flags: superreview?(dbaron)
Attachment #215146 - Flags: review?(dbaron)
Attachment #209700 - Flags: superreview?(dbaron)
Attachment #209700 - Flags: review?(dbaron)
Created attachment 219012 [details] [diff] [review]
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?
Attachment #215146 - Attachment is obsolete: true
Attachment #219012 - Flags: superreview?(dbaron)
Attachment #219012 - Flags: review?(jshin1987)
Attachment #215146 - Flags: superreview?(dbaron)
Attachment #215146 - Flags: review?(dbaron)
Created attachment 219023 [details] [diff] [review]
Patch rv3.1
Attachment #219012 - Attachment is obsolete: true
Attachment #219023 - Flags: superreview?(dbaron)
Attachment #219023 - Flags: review?(jshin1987)
Attachment #219012 - Flags: superreview?(dbaron)
Attachment #219012 - Flags: review?(jshin1987)
(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).
(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.
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.
(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.
(Assignee)

Updated

12 years ago
Summary: Implement '-moz-ime-mode' property (compatible property of WinIE's 'ime-mode') → Implement 'ime-mode' property (WinIE CSS)

Comment 35

12 years ago
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.
Attachment #219023 - Flags: review?(jshin1987)
(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.
Created attachment 226926 [details] [diff] [review]
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.
Attachment #219023 - Attachment is obsolete: true
Attachment #226926 - Flags: superreview?(dbaron)
Attachment #226926 - Flags: review?(dbaron)
Attachment #219023 - Flags: superreview?(dbaron)
Created attachment 226927 [details]
testcase3 (for without prefix)
Attachment #204443 - Attachment is obsolete: true
Attachment #209699 - Attachment is obsolete: true
(Assignee)

Updated

12 years ago
Depends on: 358899
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?
(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.
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).
Thank you. I'm busy now, therefore, I need a few days for the new patch. Please wait, thanks.
Created attachment 264848 [details] [diff] [review]
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.
Attachment #226926 - Attachment is obsolete: true
Attachment #264848 - Flags: superreview?(dbaron)
Attachment #264848 - Flags: review?(dbaron)
Attachment #226926 - Flags: superreview?(dbaron)
Attachment #226926 - Flags: review?(dbaron)
Created attachment 264849 [details]
testcase 4 (enabled -> normal)
Attachment #226927 - Attachment is obsolete: true
(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.
Or, roc is better, |nsEditor::GetPreferredIMEState| was created by roc's review.
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.
Attachment #264848 - Flags: superreview?(dbaron)
Attachment #264848 - Flags: superreview+
Attachment #264848 - Flags: review?(dbaron)
Attachment #264848 - Flags: review+
QA Contact: amyy → i18n
Created attachment 265004 [details] [diff] [review]
Patch rv4.1 (for checking-in)

Thank you, dbaron!
Attachment #264848 - Attachment is obsolete: true
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
Status: ASSIGNED → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → FIXED
(Assignee)

Updated

11 years ago
Target Milestone: mozilla1.9alpha1 → mozilla1.9alpha5
The mac testing tinderbox sometimes randomly goes orange (maybe it's a crash on shutdown).  Nothing to worry about.
Thank you, the testing after it succeeded.

Updated

11 years ago
Flags: in-testsuite?
Keywords: dev-doc-needed

Comment 52

11 years ago
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?
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.
Created attachment 266263 [details]
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.
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
Keywords: dev-doc-needed → dev-doc-complete
Sheppy:

Thank you for your work!

I find a mistake. 'deactivated' of the value is not correct. It's 'disabled'.
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.
Does that mean we're not matching IE here?  Should we be?
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.)
Depends on: 559754
Keywords: inputmethod
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
You need to log in before you can comment on or make changes to this bug.