Closed Bug 1240170 Opened 6 years ago Closed 6 years ago

Japanese IME won't join a consonant and a vowel on TweetDeck's Tweet field

Categories

(Web Compatibility :: Desktop, defect)

x86
All
defect
Not set
major

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: r_kato, Assigned: masayuki)

References

Details

(5 keywords)

Attachments

(1 file)

Attached image jp_ime_tweetdeck.jpg
User Agent: Mozilla/5.0 (Windows NT 6.1; rv:43.0) Gecko/20100101 Firefox/43.0
Build ID: 20160105164030

Steps to reproduce:

Firefox 43.0.4
x86_32 Windows 7
Microsoft Office IME 2010 (14.0.7162.5000) SP2
Google 日本語入力 2.17.2400.0

1. Sign in to TweetDeck (https://tweetdeck.twitter.com).
2. Open the Tweet field, and try to input Japanese words into the field.


Actual results:

As you can see in the attached image, my IME (both Microsoft's and Google's) isn't working well. I typed "bagujira", so expected output should be "ばぐじら", but the actual output is "bあgうjいrあ".

Also, while I'm typing some Japanese words, the wavy underline which indicates pre-conversion doesn't appear. That is almost as if I pressed Enter every time any key was pressed down...

Strange to say, however, my IME do work well on other page (such as bugzilla). 

I tried refreshing my Firefox's profile, but my IME still don't work. I tried using another browser, Google Chrome, but this issue doesn't appear.


Expected results:

IME should work well (if "bagjira" is typed, "ばぐじら" is outputed).
Component: Untriaged → Widget: Win32
Keywords: intl
Product: Firefox → Core
OS: Unspecified → Windows 7
Hardware: Unspecified → x86
Regression window:
  https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=db0f91911578db121cd5d5e26ad13ccabb1f7a79&tochange=541e2c3f465f826f1e1e66d204e86f2d9cf10c69

it seems to be related to bug 549674 tho, it was landed to Firefox 41, so maybe this time's issue is from the change in TweetDeck side?
Blocks: 549674
Status: UNCONFIRMED → NEW
Component: Widget: Win32 → Editor
Ever confirmed: true
(In reply to Tooru Fujisawa [:arai] from comment #1)
> it seems to be related to bug 549674 tho, it was landed to Firefox 41, so
> maybe this time's issue is from the change in TweetDeck side?

Probably so, because this issue appear suddenly one day. Judging from the twitter's search result of "tweetdeck firefox", other users are also suffering from this issue...

https://twitter.com/search?q=tweetdeck%20firefox&src=typd
(In reply to Tooru Fujisawa [:arai] from comment #1)
> Regression window:
>  
> https://hg.mozilla.org/integration/mozilla-inbound/
> pushloghtml?fromchange=db0f91911578db121cd5d5e26ad13ccabb1f7a79&tochange=541e
> 2c3f465f826f1e1e66d204e86f2d9cf10c69
> 
> it seems to be related to bug 549674 tho, it was landed to Firefox 41, so
> maybe this time's issue is from the change in TweetDeck side?

Yeah, it should be. When I worked on bug 1109410, there were no problems on TweetDeck.
Keywords: inputmethod
Summary: [IME] Japanese IME won't join a consonant and a vowel on TweetDeck's Tweet field → Japanese IME won't join a consonant and a vowel on TweetDeck's Tweet field
I wonder, if the cause of committing composition is setting value of the <textarea>, why other browsers won't commit the composition?? The fix of bug 549674 changed our behavior for making same behavior as the other browsers... TweetDeck sets the value only on Firefox??
I confirmed by debug build. This is actually caused by setting value attribute of <textarea>:

>>	xul.dll!mozilla::TextComposition::RequestToCommit(nsIWidget * aWidget, bool aDiscard) Line 474	C++
>  	xul.dll!mozilla::IMEStateManager::NotifyIME(const mozilla::widget::IMENotification & aNotification, nsIWidget * aWidget, bool aOriginIsRemote) Line 1470	C++
>  	xul.dll!mozilla::IMEStateManager::NotifyIME(mozilla::widget::IMEMessage aMessage, nsIWidget * aWidget, bool aOriginIsRemote) Line 1337	C++
>  	xul.dll!mozilla::IMEStateManager::NotifyIME(mozilla::widget::IMEMessage aMessage, nsPresContext * aPresContext, bool aOriginIsRemote) Line 1517	C++
>  	xul.dll!nsEditor::ForceCompositionEnd() Line 2072	C++
>  	xul.dll!nsTextEditorState::SetValue(const nsAString_internal & aValue, unsigned int aFlags) Line 1955	C++
>  	xul.dll!mozilla::dom::HTMLTextAreaElement::SetValueInternal(const nsAString_internal & aValue, unsigned int aFlags) Line 307	C++
>  	xul.dll!mozilla::dom::HTMLTextAreaElement::SetValue(const nsAString_internal & aValue) Line 328	C++
>  	xul.dll!mozilla::dom::HTMLTextAreaElementBinding::set_value(JSContext * cx, JS::Handle<JSObject *> obj, mozilla::dom::HTMLTextAreaElement * self, JSJitSetterCallArgs args) Line 770	C++
>  	xul.dll!mozilla::dom::GenericBindingSetter(JSContext * cx, unsigned int argc, JS::Value * vp) Line 2682	C++
>  	xul.dll!js::CallJSNative(JSContext * cx, bool (JSContext *, unsigned int, JS::Value *) * native, const JS::CallArgs & args) Line 235	C++
>  	xul.dll!js::Invoke(JSContext * cx, const JS::CallArgs & args, js::MaybeConstruct construct) Line 479	C++
>  	xul.dll!js::Invoke(JSContext * cx, const JS::Value & thisv, const JS::Value & fval, unsigned int argc, const JS::Value * argv, JS::MutableHandle<JS::Value> rval) Line 531	C++
>  	xul.dll!js::InvokeSetter(JSContext * cx, const JS::Value & thisv, JS::Value fval, JS::Handle<JS::Value> v) Line 649	C++
>  	xul.dll!SetExistingProperty(JSContext * cx, JS::Handle<js::NativeObject *> obj, JS::Handle<jsid> id, JS::Handle<JS::Value> v, JS::Handle<JS::Value> receiver, JS::Handle<js::NativeObject *> pobj, JS::Handle<js::Shape *> shape, JS::ObjectOpResult & result) Line 2289	C++
>  	xul.dll!js::NativeSetProperty(JSContext * cx, JS::Handle<js::NativeObject *> obj, JS::Handle<jsid> id, JS::Handle<JS::Value> value, JS::Handle<JS::Value> receiver, js::QualifiedBool qualified, JS::ObjectOpResult & result) Line 2323	C++
>  	xul.dll!js::SetProperty(JSContext * cx, JS::Handle<JSObject *> obj, JS::Handle<jsid> id, JS::Handle<JS::Value> v, JS::Handle<JS::Value> receiver, JS::ObjectOpResult & result) Line 1488	C++
>  	xul.dll!SetPropertyOperation(JSContext * cx, JSOp op, JS::Handle<JS::Value> lval, JS::Handle<jsid> id, JS::Handle<JS::Value> rval) Line 290	C++
>  	xul.dll!Interpret(JSContext * cx, js::RunState & state) Line 2599	C++
>  	xul.dll!js::RunScript(JSContext * cx, js::RunState & state) Line 426	C++
>  	xul.dll!js::Invoke(JSContext * cx, const JS::CallArgs & args, js::MaybeConstruct construct) Line 497	C++
>  	xul.dll!js::fun_call(JSContext * cx, unsigned int argc, JS::Value * vp) Line 1198	C++
Component: Editor → Desktop
Product: Core → Tech Evangelism
Version: 43 Branch → Trunk
fwiw, while bisecting with 32bit nightly on Windows 10, with Microsoft IME, it shows different behavior depending on e10s.

when I enable e10s, it shows exactly same behavior as comment #0, so "bあgうjいrあ" is entered in the textarea.
when I disable e10s (not non-e10s window), only first character is shown, so only "b" is entered in textarea (same as http://forums.mozillazine.jp/viewtopic.php?f=2&t=15874 ), but suggestion window is shown at the top left corner of the window, with "ばぐじら" text.
both issues happen from bug 549674, and looks like both are reported in twitter.
Whether e10s is enabled or not, "bあgうjいrあ" is entered in the textarea. I confirmed this with 32bit Nightly on Windows 7.

By the way, the post (http://forums.mozillazine.jp/viewtopic.php?f=2&t=15874) made me remember executing a Windows Update last night! This issue seems to have appeared after I did the Windows Update...
I'm experiencing the same issue on Firefox 43 for OS X today. With the built-in IME, "ばぐじら" will be "bあgうjいrあ". With ATOK 2015, only "b" is filled in the Tweet form.
OS: Windows 7 → All
FYI, I tried old Firefox ESR(31.8) on Windows7, and it could type Japanese correctly.
When bug 1240336 is fixed, you'll be able to type Japanese correctly again.

I tweeted a small follow-up to Kohei's tweet to explain the issue and the potential workaround. IMO we need to ship the fix ASAP though.
they deployed a fix.
https://twitter.com/andyhume/status/689807954934120448

confirmed I can enter "ばぐじら" by typing "bagujira", on nightly.
I confirmed the TweetDeck's fix too. Firefox 43.0.4 is OK :)
Thank you everyone. This is now fixed!!
Assignee: nobody → masayuki
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
-> v.
Severity: normal → major
Status: RESOLVED → VERIFIED
Product: Tech Evangelism → Web Compatibility
You need to log in before you can comment on or make changes to this bug.