632744 - Keystroke doesn't work on auto-completion of Fennec awesome screen after selected list item

Status: VERIFIED FIXED

(Firefox for Android Graveyard :: General, defect)

Description

[Makoto Kato [:m_kato]]

- Env
Fennec Andorid nightly
Fennec Win32 nightly

- Step
1. Focus address bar to use auto completion for search engine
2. Using virtual Japanese keyboard, type "あ", "あ" and "あ". (Don't commit composition string!)
3. Select Google - search for "あああ"

Result
"あああ" on text box is erased.  Then, all input is ignore until [確定 / Enter] key on virtual keyboard is typed.  Even if it isn't Japanese IME keyboard, this will occur on prediction virtual keyboard.

Expected result
search is started.


On debug build, this step hits the following assertion (on Windows)

0:000> k 200
ChildEBP RetAddr
00239b58 5dde0f26 ntdll!DbgBreakPoint
00239e68 5dde11b5 xul!Break+0x166
0023a288 5d9fabdd xul!NS_DebugBreak_P+0x25c
0023a318 5d9fa7f5 xul!IMETextTxn::CollapseTextSelection+0x2d3
0023a338 5d21e058 xul!IMETextTxn::DoTransaction+0x9a
0023a340 5d220b5e xul!nsTransactionItem::DoTransaction+0x13
0023a358 5d21f6a9 xul!nsTransactionManager::BeginTransaction+0x61
0023a370 5d9eba33 xul!nsTransactionManager::DoTransaction+0x78
0023a3a4 5d9f18d6 xul!nsEditor::DoTransaction+0x284
0023a484 5d9f2005 xul!nsEditor::InsertTextIntoTextNodeImpl+0x27e
0023a4c0 5d9e3c15 xul!nsEditor::InsertTextImpl+0x47e
0023a5c4 5d9e41eb xul!nsTextEditRules::WillInsertText+0x54e
0023a5f0 5d9df0f1 xul!nsTextEditRules::WillDoAction+0x9c
0023a714 5d89e8ca xul!nsPlaintextEditor::InsertText+0x192
0023a82c 5d88d97d xul!nsTextEditorState::SetValue+0x389
0023a8e8 5d88fa1a xul!nsHTMLInputElement::SetValueInternal+0xa9
0023a910 5dc128f5 xul!nsHTMLInputElement::SetValue+0x73
0023a968 6895ffaa xul!nsIDOMHTMLInputElement_SetValue+0x9f
0023a9a8 68961ebc mozjs!js::Shape::set+0x10a
0023aa20 689355c0 mozjs!js_SetPropertyHelper+0x30c
0023b168 6892c389 mozjs!js::Interpret+0x5970
0023b188 6892f0bb mozjs!js::RunScript+0xc9
0023b1d0 6892f34c mozjs!js::Invoke+0x2bb
0023b20c 6892f5a6 mozjs!js::ExternalInvoke+0x15c
0023b238 6895fefe mozjs!js::ExternalGetOrSet+0x76
0023b268 68961ebc mozjs!js::Shape::set+0x5e
0023b2e0 689355c0 mozjs!js_SetPropertyHelper+0x30c
0023ba18 6892c389 mozjs!js::Interpret+0x5970
0023ba38 6892f0bb mozjs!js::RunScript+0xc9
0023ba80 6892f34c mozjs!js::Invoke+0x2bb
0023babc 6892f5a6 mozjs!js::ExternalInvoke+0x15c
0023bae8 6895fefe mozjs!js::ExternalGetOrSet+0x76
0023bb18 68961ebc mozjs!js::Shape::set+0x5e
0023bb90 68962460 mozjs!js_SetPropertyHelper+0x30c
0023bbac 688969c2 mozjs!js_SetProperty+0x20
0023bbd8 68896afa mozjs!JS_SetPropertyById+0xd2
0023bbf4 5dc4ac4e mozjs!JS_SetProperty+0x5a
0023bea0 5dc46e59 xul!nsXPCWrappedJSClass::CallMethod+0xbe9
0023becc 5dde78f3 xul!nsXPCWrappedJS::CallMethod+0xac
0023bf88 5dde795f xul!PrepareAndDispatch+0x166
0023bfa4 5d34eb9f xul!SharedStub+0x16
0023c018 00000000 xul!nsAutoCompleteController::EnterMatch+0x34e

Comment 1

[Makoto Kato [:m_kato]]

Attachment: test case for desktop firefox

This is test case for Desktop firefox.

- Env
Windows Vista + 2011-02-08 nightly

- Step
1. Open attached HTML
2. Turn on IME
3. input "ああああ" into textbox (don't commit this!.  keep composition state.)
4. Wait 10 sec.

- Result
text into textbox is erased.  After that, when you want to input a string, you cannot input it until turning off IME or type [Enter] key.

Comment 2

[Makoto Kato [:m_kato]]

Attachment: wip v0.1

not good fix.  Why doesn't ForceCompositionEnd call nsEditorEventListener??  we should investigate this.

Comment 3

[Makoto Kato [:m_kato]]

Attachment: fix v1

Comment 4

[(no longer active)]

Don't we want to do this in InsertText perhaps?

Comment 5

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

InsertText() needs chrome permission (or is our internal code). I think that such callers should care IME themselves. And see the assertion in nsEditor. Even if we want to commit IME in InsertText(), it may fail due to the script blocker.

Comment 6

[Makoto Kato [:m_kato]]

request blocking-fennec.

On Fennec's auto-completion starts searching with composition string.  (On desktop Firefox, it doesn't run auto-completion with composition state!).

When selecting item before confirming composition string, key input on auto-completion never works until [Enter / confirmed] key is pressed.  As user experience, I think that it is critical bug for Fennec

Comment 7

[Makoto Kato [:m_kato]]

Attachment: fix v2

Comment 8

[(no longer active)]

I'll probably get to review this tomorrow.

Comment 9

[(no longer active)]

Comment on attachment 514661 [details] [diff] [review]
fix v2

># HG changeset patch
># Parent 280e978fc6fb4c731728255a8bc9c70ded2adbea
> Bug 632744 - try: -b do -p all -u crashtest,reftest -t none
>
>diff --git a/content/html/content/src/nsTextEditorState.cpp b/content/html/content/src/nsTextEditorState.cpp
>--- a/content/html/content/src/nsTextEditorState.cpp
>+++ b/content/html/content/src/nsTextEditorState.cpp
>@@ -59,16 +59,17 @@
> #include "nsINativeKeyBindings.h"
> #include "nsIDocumentEncoder.h"
> #include "nsISelectionPrivate.h"
> #include "nsPIDOMWindow.h"
> #include "nsServiceManagerUtils.h"
> #include "nsIDOMEventGroup.h"
> #include "nsIEditor.h"
> #include "nsTextEditRules.h"
>+#include "nsIEditorIMESupport.h"
> 
> #include "nsTextEditorState.h"
> 
> using namespace mozilla::dom;
> 
> static NS_DEFINE_CID(kTextEditorCID, NS_TEXTEDITOR_CID);
> static NS_DEFINE_CID(kFrameSelectionCID, NS_FRAMESELECTION_CID);
> 
>@@ -1725,16 +1726,26 @@ nsTextEditorState::GetValue(nsAString& a
>     }
>   }
> }
> 
> void
> nsTextEditorState::SetValue(const nsAString& aValue, PRBool aUserInput)
> {
>   if (mEditor && mBoundFrame) {
>+    // commit composition string to sync IME state
>+    // commited text will be replaced with setting value.
>+    nsCOMPtr<nsIEditorIMESupport> imeEditor = do_QueryInterface(mEditor);
>+    if (imeEditor) {
>+      PRBool hasComposition;

Initialize this to PR_FALSE please, and then ignore the return value of GetComposing and just check hasComposition.

>+      if (NS_SUCCEEDED(imeEditor->GetComposing(&hasComposition)) &&
>+          hasComposition)
>+        imeEditor->ForceCompositionEnd();
>+    }

How do other browsers (Webkit based browsers, IE and Opera) behave when the js code sets the value property while an IME composition is in progress?

Also, I had asked if we should do this in InsertText, to which you replied:

(In reply to comment #5)
> InsertText() needs chrome permission (or is our internal code).

So is committing the IME transaction.

> I think that
> such callers should care IME themselves.

Well, have you looked at other InsertText callers then?  For example, here is what the spell checker code does when you replace a misspelling with a suggestion: <http://mxr.mozilla.org/mozilla-central/source/extensions/spellcheck/src/mozInlineSpellChecker.cpp#864>.  What should happen to possible IME transactions in progress?

> And see the assertion in nsEditor.
> Even if we want to commit IME in InsertText(), it may fail due to the script
> blocker.

So, does committing IME transactions include running scripts?  If so, why?

>diff --git a/toolkit/components/autocomplete/src/nsAutoCompleteController.cpp b/toolkit/components/autocomplete/src/nsAutoCompleteController.cpp
>--- a/toolkit/components/autocomplete/src/nsAutoCompleteController.cpp
>+++ b/toolkit/components/autocomplete/src/nsAutoCompleteController.cpp
>@@ -1182,16 +1182,18 @@ nsAutoCompleteController::EnterMatch(PRB
>     mozilla::services::GetObserverService();
>   NS_ENSURE_STATE(obsSvc);
>   obsSvc->NotifyObservers(input, "autocomplete-will-enter-text", nsnull);
> 
>   if (!value.IsEmpty()) {
>     input->SetTextValue(value);
>     input->SelectTextRange(value.Length(), value.Length());
>     mSearchString = value;
>+    // SetTextValue may cause compoistion end event, so reset flag
>+    mIgnoreHandleText = PR_FALSE;

Why is this necessary?


Also, I think we should get at least two types of tests here, one testing the effect of setting the value property while an IME transaction is in progress, and the other testing the autocomplete widget in that situation.

Comment 10

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

(In reply to comment #9)
> > I think that
> > such callers should care IME themselves.
> 
> Well, have you looked at other InsertText callers then?  For example, here is
> what the spell checker code does when you replace a misspelling with a
> suggestion:
> <http://mxr.mozilla.org/mozilla-central/source/extensions/spellcheck/src/mozInlineSpellChecker.cpp#864>.
>  What should happen to possible IME transactions in progress?

The suggestion is on context menu. We do commit composition forcibly if it's opened during composition. So, this code is safe for now.

I guess that some callers want to cancel the composition rather than commit. But even if so, committing by InserText() isn't problem because such callers should cancel the composition before it. (there is no API for canceling composition now but addon developers can cancel the composition if they use native code.)

So, even if we call ForceCompositionEnd() in InsertText(), it may not cause any troubles. But...

> > And see the assertion in nsEditor.
> > Even if we want to commit IME in InsertText(), it may fail due to the script
> > blocker.
> 
> So, does committing IME transactions include running scripts?  If so, why?

If content's script behavior causes running a function which is calling InserText(), won't committing composition fail?

> Also, I think we should get at least two types of tests here, one testing the
> effect of setting the value property while an IME transaction is in progress,
> and the other testing the autocomplete widget in that situation.

Unfortunately, we cannot test the former. nsIEditrIMESupport::ForceCompositionEnd() calls nsIWidget::ResetInputState(). ResetInputState() does *not* dispatch any composition events. It requests the native IME to commit composition. So, when we want to test the ForceCompositionEnd(), we need to generate composition with native IME. But it's impossible.

Comment 11

[(no longer active)]

(In reply to comment #10)
> (In reply to comment #9)
> > > I think that
> > > such callers should care IME themselves.
> > 
> > Well, have you looked at other InsertText callers then?  For example, here is
> > what the spell checker code does when you replace a misspelling with a
> > suggestion:
> > <http://mxr.mozilla.org/mozilla-central/source/extensions/spellcheck/src/mozInlineSpellChecker.cpp#864>.
> >  What should happen to possible IME transactions in progress?
> 
> The suggestion is on context menu. We do commit composition forcibly if it's
> opened during composition. So, this code is safe for now.

What if an add-on provides alternate UI?  I was merely trying to point that there are use cases of InsertText that are *not* setting the value property.

> I guess that some callers want to cancel the composition rather than commit.
> But even if so, committing by InserText() isn't problem because such callers
> should cancel the composition before it. (there is no API for canceling
> composition now but addon developers can cancel the composition if they use
> native code.)

Exactly, so we shouldn't worry about that.

> So, even if we call ForceCompositionEnd() in InsertText(), it may not cause any
> troubles. But...

I'm not sure which part of the rest of your comment is the reason to not do this in InsertText.  If you're pointing to content script getting run, see below.  Still I don't see why this can't be done in InsertText.

> > > And see the assertion in nsEditor.
> > > Even if we want to commit IME in InsertText(), it may fail due to the script
> > > blocker.
> > 
> > So, does committing IME transactions include running scripts?  If so, why?
> 
> If content's script behavior causes running a function which is calling
> InserText(), won't committing composition fail?

Firstly, you're confusing two things.  I was talking about content script running as a result of calling ForceEndComposition.  This requires there to be a way for content code to run a script while ForceEndComposition is processed (for example, if we dispatch an event as part of that function).  As far as I can see, there is no way for that to happen.  Therefore I'm asserting that it's safe to call ForceEndComposition from within InsertText.

You're talking about content script doing something which results in InsertText getting called.  That is totally possible.  Consider this testcase:

<input type=text id=x>
<script>
var x=document.getElementById('x');
setInterval(function() { x.value = x.value; }, 100);
</script>

This will cause nsHTMLInputElement::SetValue to be called ten times a second, which causes InsertText to be called internally.  Now, with your patch, this page would practically make it impossible for people to use IME (because we would end up calling ForceEndComposition every 100 milliseconds!).  Is this really what we want to do here?  I don't think so.

I ask this question again: what do other browsers do.  Unless they all cancel IME on setting the value attribute, we should not start doing that.

> > Also, I think we should get at least two types of tests here, one testing the
> > effect of setting the value property while an IME transaction is in progress,
> > and the other testing the autocomplete widget in that situation.
> 
> Unfortunately, we cannot test the former.
> nsIEditrIMESupport::ForceCompositionEnd() calls nsIWidget::ResetInputState().
> ResetInputState() does *not* dispatch any composition events. It requests the
> native IME to commit composition. So, when we want to test the
> ForceCompositionEnd(), we need to generate composition with native IME. But
> it's impossible.

OK, but the latter should still be testable, right?  (The former we might not end up doing anyways)

Comment 12

[Makoto Kato [:m_kato]]

(In reply to comment #9)
> Comment on attachment 514661 [details] [diff] [review]
> fix v2
> 
> ># HG changeset patch
> ># Parent 280e978fc6fb4c731728255a8bc9c70ded2adbea
> > Bug 632744 - try: -b do -p all -u crashtest,reftest -t none
> >
> >diff --git a/content/html/content/src/nsTextEditorState.cpp b/content/html/content/src/nsTextEditorState.cpp
> >--- a/content/html/content/src/nsTextEditorState.cpp
> >+++ b/content/html/content/src/nsTextEditorState.cpp
> >@@ -59,16 +59,17 @@
> > #include "nsINativeKeyBindings.h"
> > #include "nsIDocumentEncoder.h"
> > #include "nsISelectionPrivate.h"
> > #include "nsPIDOMWindow.h"
> > #include "nsServiceManagerUtils.h"
> > #include "nsIDOMEventGroup.h"
> > #include "nsIEditor.h"
> > #include "nsTextEditRules.h"
> >+#include "nsIEditorIMESupport.h"
> > 
> > #include "nsTextEditorState.h"
> > 
> > using namespace mozilla::dom;
> > 
> > static NS_DEFINE_CID(kTextEditorCID, NS_TEXTEDITOR_CID);
> > static NS_DEFINE_CID(kFrameSelectionCID, NS_FRAMESELECTION_CID);
> > 
> >@@ -1725,16 +1726,26 @@ nsTextEditorState::GetValue(nsAString& a
> >     }
> >   }
> > }
> > 
> > void
> > nsTextEditorState::SetValue(const nsAString& aValue, PRBool aUserInput)
> > {
> >   if (mEditor && mBoundFrame) {
> >+    // commit composition string to sync IME state
> >+    // commited text will be replaced with setting value.
> >+    nsCOMPtr<nsIEditorIMESupport> imeEditor = do_QueryInterface(mEditor);
> >+    if (imeEditor) {
> >+      PRBool hasComposition;
> 
> Initialize this to PR_FALSE please, and then ignore the return value of
> GetComposing and just check hasComposition.
> 
> >+      if (NS_SUCCEEDED(imeEditor->GetComposing(&hasComposition)) &&
> >+          hasComposition)
> >+        imeEditor->ForceCompositionEnd();
> >+    }
> 
> How do other browsers (Webkit based browsers, IE and Opera) behave when the js
> code sets the value property while an IME composition is in progress?

All browser's behaviors are different.  (Except to Safari, this causes another bug :-<)

Safari 5 ... It cancels IME composition, then value is set by script.
IE 9 ... It sets value at first.  But, if you input any character, it replace the value on input with original composition string.
Opera 11 ... It sets value and next is composition string that user is inputted.  But drawing composition status is incorrectly (underline for composition is painted on non-composition string).
Chrome 10 ... It sets value and replace some chracters with composition string.  Drawing composition status is incorrectly at first (underline for composition is painted on non-composition string).
Firefox 4 ... It doesn't set value and it cannot input any characters until [enter] key is pressed.

Firefox's behavioral is worst.  At least, key input should be allowed after setting value by script.

> 
> Also, I had asked if we should do this in InsertText, to which you replied:
> 
> (In reply to comment #5)
> > InsertText() needs chrome permission (or is our internal code).
> 
> So is committing the IME transaction.
> 
> > I think that
> > such callers should care IME themselves.
> 
> Well, have you looked at other InsertText callers then?  For example, here is
> what the spell checker code does when you replace a misspelling with a
> suggestion:
> <http://mxr.mozilla.org/mozilla-central/source/extensions/spellcheck/src/mozInlineSpellChecker.cpp#864>.
>  What should happen to possible IME transactions in progress?
> 
> > And see the assertion in nsEditor.
> > Even if we want to commit IME in InsertText(), it may fail due to the script
> > blocker.
> 
> So, does committing IME transactions include running scripts?  If so, why?
> 
> >diff --git a/toolkit/components/autocomplete/src/nsAutoCompleteController.cpp b/toolkit/components/autocomplete/src/nsAutoCompleteController.cpp
> >--- a/toolkit/components/autocomplete/src/nsAutoCompleteController.cpp
> >+++ b/toolkit/components/autocomplete/src/nsAutoCompleteController.cpp
> >@@ -1182,16 +1182,18 @@ nsAutoCompleteController::EnterMatch(PRB
> >     mozilla::services::GetObserverService();
> >   NS_ENSURE_STATE(obsSvc);
> >   obsSvc->NotifyObservers(input, "autocomplete-will-enter-text", nsnull);
> > 
> >   if (!value.IsEmpty()) {
> >     input->SetTextValue(value);
> >     input->SelectTextRange(value.Length(), value.Length());
> >     mSearchString = value;
> >+    // SetTextValue may cause compoistion end event, so reset flag
> >+    mIgnoreHandleText = PR_FALSE;
> 
> Why is this necessary?

Auto completion doesn't consider calling SetTextValue during composition.  So it will hit another assertion because mIgnoreHandleText is true.

Comment 13

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

(In reply to comment #11)
> (In reply to comment #10)
> > (In reply to comment #9)
> > > > I think that
> > > > such callers should care IME themselves.
> > > 
> > > Well, have you looked at other InsertText callers then?  For example, here is
> > > what the spell checker code does when you replace a misspelling with a
> > > suggestion:
> > > <http://mxr.mozilla.org/mozilla-central/source/extensions/spellcheck/src/mozInlineSpellChecker.cpp#864>.
> > >  What should happen to possible IME transactions in progress?
> > 
> > The suggestion is on context menu. We do commit composition forcibly if it's
> > opened during composition. So, this code is safe for now.
> 
> What if an add-on provides alternate UI?

Good point. I'm not familiar with the implementation of the spellchecker, but I guess it's possible.

> > > > And see the assertion in nsEditor.
> > > > Even if we want to commit IME in InsertText(), it may fail due to the script
> > > > blocker.
> > > 
> > > So, does committing IME transactions include running scripts?  If so, why?
> > 
> > If content's script behavior causes running a function which is calling
> > InserText(), won't committing composition fail?
> 
> Firstly, you're confusing two things.  I was talking about content script
> running as a result of calling ForceEndComposition.  This requires there to be
> a way for content code to run a script while ForceEndComposition is processed
> (for example, if we dispatch an event as part of that function).  As far as I
> can see, there is no way for that to happen.  Therefore I'm asserting that it's
> safe to call ForceEndComposition from within InsertText.
> 
> You're talking about content script doing something which results in InsertText
> getting called.  That is totally possible.  Consider this testcase:
> 
> <input type=text id=x>
> <script>
> var x=document.getElementById('x');
> setInterval(function() { x.value = x.value; }, 100);
> </script>
> 
> This will cause nsHTMLInputElement::SetValue to be called ten times a second,
> which causes InsertText to be called internally.  Now, with your patch, this
> page would practically make it impossible for people to use IME (because we
> would end up calling ForceEndComposition every 100 milliseconds!).  Is this
> really what we want to do here?  I don't think so.

Hey, the patch isn't mine. Kato-san is working for this. I just comment some advices.

Okay, but I still worry about the problem. Ideally, we should guarantee that all IME events are received by editor in composition. I keep this issue in my mind.

> > > Also, I think we should get at least two types of tests here, one testing the
> > > effect of setting the value property while an IME transaction is in progress,
> > > and the other testing the autocomplete widget in that situation.
> > 
> > Unfortunately, we cannot test the former.
> > nsIEditrIMESupport::ForceCompositionEnd() calls nsIWidget::ResetInputState().
> > ResetInputState() does *not* dispatch any composition events. It requests the
> > native IME to commit composition. So, when we want to test the
> > ForceCompositionEnd(), we need to generate composition with native IME. But
> > it's impossible.
> 
> OK, but the latter should still be testable, right?  (The former we might not
> end up doing anyways)

I'm not sure about the latter. As I said, ForceCompositionEnd() does *not* dispatch any composition/text events if we're emulating the composition by nsIDOMWindowUtils.

And I think that I killed the autocomplete during composition on toolkit level due to there is an a11y problem (autocomplete suggestion list overlaps IME's candidate window). So, even if it's needed by Fennec, I don't think that this can be tested on Fx.

Comment 14

[Makoto Kato [:m_kato]]

(In reply to comment #11)
> Firstly, you're confusing two things.  I was talking about content script
> running as a result of calling ForceEndComposition.  This requires there to be
> a way for content code to run a script while ForceEndComposition is processed
> (for example, if we dispatch an event as part of that function).  As far as I
> can see, there is no way for that to happen.  Therefore I'm asserting that it's
> safe to call ForceEndComposition from within InsertText.
> 
> You're talking about content script doing something which results in InsertText
> getting called.  That is totally possible.  Consider this testcase:
> 
> <input type=text id=x>
> <script>
> var x=document.getElementById('x');
> setInterval(function() { x.value = x.value; }, 100);
> </script>
> 
> This will cause nsHTMLInputElement::SetValue to be called ten times a second,
> which causes InsertText to be called internally.  Now, with your patch, this
> page would practically make it impossible for people to use IME (because we
> would end up calling ForceEndComposition every 100 milliseconds!).  Is this
> really what we want to do here?  I don't think so.

So this fix checks whether there is composition string.  If nothing, it doesn't call force commit.
After committing composition string by ForceEndComposition, composition string is nothing.

Comment 15

[Makoto Kato [:m_kato]]

Ehsan, how do you think about right behavior for this test case?  All major browser's behavior (comment #12) is different and there is no specification for this.

Also, although I posted to WHATWG about this issue today (http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-February/030656.html), we may need long time to decide right behavior.  And, to change behavior, it may be risk (We have to go to RC!).  So we should discuss this by another bug such as bug 549674.

But this is a Fennec blocker.  So I will create new patch to add hack to mobile-browser.

Comment 16

[Makoto Kato [:m_kato]]

Attachment: fix v3

Comment 18

[Mark Finkle (:mfinkle) (use needinfo?)]

Comment on attachment 515016 [details] [diff] [review]
fix v3

I'm OK with taking this patch if we can't get a platform fix in time for Fennec 2

Comment 19

[Makoto Kato [:m_kato]]

landed
http://hg.mozilla.org/mobile-browser/rev/52452e0d8d07

about root cause will discuss on bug 549674.  It depends on standard spec.

Comment 20

[(no longer active)]

(In reply to comment #15)
> Ehsan, how do you think about right behavior for this test case?  All major
> browser's behavior (comment #12) is different and there is no specification for
> this.
> 
> Also, although I posted to WHATWG about this issue today
> (http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-February/030656.html),
> we may need long time to decide right behavior.  And, to change behavior, it
> may be risk (We have to go to RC!).  So we should discuss this by another bug
> such as bug 549674.

Hmm, the current behavior of all browsers seems to be a mess.  I'm not really sure what's the right thing to do here, for example, a web page might set the value property to "ab" while it's currently "abc" in order to simulate a backspace key...

I personally think that the most sane behavior is for the IME transaction to be aborted, but let's decide that on the WHATWG list now that the Fennec specific issue is fixed.

Comment 21

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

Mozilla/5.0 (Android; Linux armv71; rv2.0b13pre) Gecko/20110317 Firefox/4.0b13pre Fennec/4.0b6pre
Device: Droid 2 
OS: Android 2.2