I am using Debian GNU/Linux.
I am inputting Japanese text to X-based applications such as Mozilla FF or
TB using a frontend that uses XIM protocol: specifically, kinput2-wnn is
what I use.

Since January of 2018 (last year) or earlier, I have seen the following problem
with FF and TB. Other X-based programs on the same computer don't
suffer from the same problem.
So I suspect certain issue(s) of event handling in mozilla GUI modules.

The conversion of Kana (phonetical character) string to mixed string of
Kanjis (Chinese characters) and Kanas does not work well any more [it used
to work] because the visual feedback of choosing different candidate string
is not given any more during selection process. The next alternative
selection string, which used to be painted on the screen, when I hit
the conversion key (usually mapped to [SPACE]), does not always happen
any more. This is very confusing.
Only when I hit the key to signal the end of the conversion process, the
finally chosen string is painted on the screen. (This still happens
all the time.)
But since I cannot see the tentatve alternative selectrion string, I
have no idea what would be the finally chosen string.

I suspect that there is a slight change in the way X event is handled in the
GUI library of mozilla software (maybe GTK?) that somehow masks the repaint
request event (see below)?

How? Let me try to explain the symptom in more detail.

Symptom:

To start with, the first conversion from Kana to the first choice of the
mixed string string may or may not work. It should work.

e.g. control-space triggers Japanese input mode. I hit "toyodaigaku" to get
the following kana-only string.

とうようだいがく

See attachment-0.png.

I hit [space] to obtain the first Kana-Kanji mixed string. But the
conversion to the mixed string is NOT shown on the screen.
The string selected is only internally kept, but not shown on the screen.

It used to work with mozilla TB and FF under linux.
Currently, for a different application called MousePad (a simple
editor) the converted string is shown on the screen at each conversion request.

See attachment-1.png

However, if the choice is not correct, human users wants to select ANOTHER
choice.

This is most often done by hitting a conversion key, often SPACE BAR
(configurable) by kinput2 frontend.

However, the problem is that NO REPAINTING of the selected new string
happens in TB (and FF). It used to happen.
So we get stuck with the stale original string instead of the new
alternative candidate of conversion.

(HOWEVER, obviously internally, the selected string CHANGES ! I know this
because when I hit [NEWLINE] to signal the end of conversion, the
the final string IS shown on the screen, and the selected string DOES
change when the number of [SPACE]s hit is different!)

This means the user does not get visual feedback and flies with instrument
only, so to speak.
But in this instance, I have no idea what the selected choice of the
conversion string is at all (!)

At the end, when I type [ENTER] or [NEWLINE], the internally selected final
choice is shown. Unfortunately, it is often not the one I want at all.

How do I know that the selected string CHANGES? Because, the finally shown
conversion string changes after a different number of [SPACE]s are hit.

Sometimes it works. But sometimes not.

I also notice one thing. Sometimes, the repainting does work when the length
of the alternative candidate string changes. Sometimes. Not always. This is
puzzling. There must be some pattern to it. But I have not been able to
figure this out.

So maybe there could some too efficient repaint code that tries to avoid
repainting based on the size of the area to be repainted, the before and
after content of the area to be repainted, etc.
But it seems too eager to avoid repainting and fail to repaint the
area occupied by the string image of successive and DIFFERENT
conversion candidates. Or there is simply a coding bug/uninitialized variable, etc.

HOWEVER, the XIM input with kinput2-wnn frontend works for other X
programs which I tested. Only mozilla FF and TB show the symptoms I
describe here.

I think the repaint code in the GUI library used by mozilla FF and TB
somehow fails to work correctly. However, the problem happens
only with with Mozilla FF and TB. I tested a few other applets under Debian
GNU/Linux. Inputting Japanese text using kinput2-wnn work as before for
these applets.

So it is possible that mozilla GUI libraries/modules may silently eats
the event code for repainting and thus TB/FF fail to update the
necessary screen area.

So it could be the bug of GUI library + mozilla's calling or setting up call
back is buggy. There can be other reasons, but I can't think of one.

Strange:
Some character strings that gets converted into a single kanji
character somehow shows the visual feedback for each conversion even
in mozilla TB and FF.
I wonder why. Maybe there is a strange interaction within GUI toolkit
used by mozilla TB and FF and XIM protocol?

There are slight variations of cases that work and that does not work.

1. A case where the repaint does happen when the altenative
   candidate is a single Kanji character.
   e.g. "ryou" that converts to りょう (phonetical symbol)
   then converts to single Kanaji charactger alternative at each [SPACE]
   key.
   りょう
   量
   両
   ...

2. A case where the FIRST conversion repaints the screen, but
   the subsequent conversion does not.

Inputting taiheiyou convers to たいへいよう automatically

(The word refers to the Pacific Ocean.)

太平洋

However, the subsequent converstion key no longer
repaints the screen. So I have no idea what the
selected string is.

See attachment-3.png

Summary:

1. I am curious if others are experiencing the same problem.

Previously the following bugs put off many East Asian users
from XIM-based input and so there are much fewer users
of XIM-based input such as kinput-wnn4 frontend.

https://bugzilla.mozilla.org/show_bug.cgi?id=787943
https://bugzilla.mozilla.org/show_bug.cgi?id=779900

But still I hate to think I am the only person in this world to
experience this bug.

2. Note: I wanted to assemble typical cases to figure out
   what is going on over the months, but could never
   come up possible scenario of what is wrong with the event
   handling so far. The few cases I mentioned are the ones I noted down
   last September and I have not made much progress.

Since other programs do work with XIM-based input method without
problems on the same computer, I am wondering how to debug the event
handling issue of mozilla libraries/modules and GTK libraries.
I appreciate some tips
to investigate the complext event handling from people in the know.

I will request information from Karl Tomlinson (:karlt) since he was very
instrumental to figure out the issue with X-11 library deficiency in
bug 787943.

PS: Since the behavior of the input frontend is hard to describe, maybe I can capture the screen on my smartphone's camera during input and put the video on youtube if that is absolutely necessary.

See the orignal comment.

This is what typing "touyoudaigaku" produces using kinput2-wnn in Roman input mode produces on the screen.

This is what typing "Touyoudaigaku" produces using kinput2-wnn4 input frontend in Roman-input mode.

See the comment 0:
After the conversion string is hit,
thunderbird does not repaint the string: thus I don't know what the currently chosen alternative candidate input string.

OTOH, a program called mousepad repaints the screen to show the
next input candiate string after each conversion key.

See commnet 0.
Strange behavior of the repainting for the input "taiheiyou", "たいへいよう".

So this is a regression? Regression range would be nice.

(In reply to Olli Pettay [:smaug] (massive needinfo queue, ping on IRC on anything urgent) from comment #5)

So this is a regression? Regression range would be nice.

Yes, I think so.

How can I obtain old TB binary files to figure out when the problem showed up?

TIA

https://mozilla.github.io/mozregression/ can work with Thunderbird, but I'd guess this is easier to reproduce in Firefox with data:text/html,<textarea>

Comparing output before and after the regression with MOZ_LOG=nsGtkIMModuleWidgets:5 in the environment may be helpful.

I doubt this is related to bug 787943.

(In reply to Karl Tomlinson (:karlt) from comment #7)

https://mozilla.github.io/mozregression/ can work with Thunderbird, but I'd guess this is easier to reproduce in Firefox with data:text/html,<textarea>

Comparing output before and after the regression with MOZ_LOG=nsGtkIMModuleWidgets:5 in the environment may be helpful.

I doubt this is related to bug 787943.

Thank you for the tips.

Will give it a try over the weekend.
This has been botherming for so long and yet I could not get a set of reasonable behavior observations to
home in the culprit.

Thank yo again.

I was not able to reproduce this issue with the latest Nightly build on Ubuntu 18.04 in order to find a regression range.
ISHIKAWA, when time permits, can you please check the regression range for this issue. Thank you!

(In reply to Anca Soncutean [:Anca], Desktop Release QA from comment #9)

I was not able to reproduce this issue with the latest Nightly build on Ubuntu 18.04 in order to find a regression range.
ISHIKAWA, when time permits, can you please check the regression range for this issue. Thank you!

Yes, I will try. I have been meaning to do this. A two and half a yera project that has sucked up my time is about to end hopefully this week with the final deliverable and THEN I should be able to report this (!).
OK, I will use Firefox as noted in comment 7.

Thank you for your patience.

I finally figured out how to use the mozregression command line (GUI version didn7t work, I think I need to set some library path for the mozregression-gui binary, but was not quite sure how to go about it.)

Anyway, the command line mozregression could narrow the problem down to the following.

INFO: Narrowed nightly regression window from [2016-03-11, 2016-03-17] (6 days) to [2016-03-14, 2016-03-17] (3 days) (~1 steps left)

INFO: Got as far as we can go bisecting nightlies...
12:58.48 INFO: Last good revision: 5e14887312d4523ab59c3f6c6c94a679cf42b496 (2016-03-15)
12:58.48 INFO: First bad revision: 341344bdec8f10bf50646cd6ef2355361435cbf6 (2016-03-16)

But, unfortunately, old builds could not be found on the taskcluster and so no more
details could be found.

47.0a1 was OK.
definitely something after the bad 48.0a1 is buggy.

So I will find out what is the difference as noted in comment 7 between these revisions.

Comparing output before and after the regression with MOZ_LOG=nsGtkIMModuleWidgets:5 in the environment may be helpful.

TIA

Regression window(from comment#11)
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=5e14887312d4523ab59c3f6c6c94a679cf42b496&tochange=341344bdec8f10bf50646cd6ef2355361435cbf6

Well, then, should be bug 1137563, although not 100% sure. I'll try to create the environment, but I have some urgent bugs now. So, perhaps, I'll be back here late next week.

(In reply to Masayuki Nakano [:masayuki] (JST, +0900) from comment #13)

Well, then, should be bug 1137563, although not 100% sure. I'll try to create the environment, but I have some urgent bugs now. So, perhaps, I'll be back here late next week.

It is likely.
Anyway, I will post the logs as suggested from comment 7.

TIA

This is for illustration of the operation with which I intend to obtain logging.

With FF F7.0.1, I can input kana-kanji string using kinput2-wnn frontend as expected.
This is the part-1 of two series.
This is up to when I get the initial kanji string candiate. (This fails in FF 48.0.1)

This shows the process where I select the final candidate and
finalize my choice. It is done under visual feedback.

This is with FF 47.0.1.

Unfortunately, this visual feedback is missing in 48.0.1, a serious regression.

With FF 48.0.1, I could not get the visual feedback to guide me in selecting the candidate kana-kanji string at all.
A serious regression to hamper Japanese input.

Please note that I am using kinput2-wnn Japanese input frontend that uses X11's XIM protocol.
This was popular around the year 2,000 and I am sure there are still diehard fans of this protocol and the frontend tools like kinput2-wnn.

You have to run kinput2-wnn BEFORE invoking Firefox to test this input.
Also, kinput2-wnn requires the backend conversion server and I use free wnn4-jserver for this.
So you have to install these tools to test this.

I suspect many popular linux distributions nowadays are preconfigured with different Japanese input subysstem / frontends.
This may be the reason why "he latest Nightly build on Ubuntu 18.04" could not be use dto narrow down the regression range.

I have been using this input subsystem based on the Japanese conversion server nn4 and commcerical variant that was available sun/oracle solaris for a LOOONG time.: I have used it extensively from within GNU Emacs and I can't simply live without it for my desktop work.
GNU Emacs has its own keyboard handler to convert romanized input to Japanese hirgarans, then to kana-kanji strings now. It is now coded completely in GNU Emacs Lisp and it iteracts with the backend conversion engine.

For generic X11 programs like FF/TB and other visual tools such as GIMP, a so-called frontend program that sits between the keyboard input and the native program does the Japanese input handling: kinput2-wnn is such a frontend and it uses XIM protocol for input processing. There are other input frondend that is based on other protocols, it seems.

If someone rquires hand-holding to start jserver and set up kinput2-wnn, etc. I can certainly give my config files, etc. so that the same procedure can be done on people's linux desktop.

However, I am hping that my upload logs (I am going to do it in the next 24 hours) and the attention of Masayuki Nakano ought to discover the root cause and hopefully a working fix in not so distant future.

TIA

(In reply to Karl Tomlinson (:karlt) from comment #7)

https://mozilla.github.io/mozregression/ can work with Thunderbird, but I'd guess this is easier to reproduce in Firefox with data:text/html,<textarea>

Comparing output before and after the regression with MOZ_LOG=nsGtkIMModuleWidgets:5 in the environment may be helpful.

I doubt this is related to bug 787943.

Hmm... Does this MOZ_LOG thing work only with a debug version?
Nothing is printed with 47.0.1.
I will investigate.

Hmm

MOZ_LOG may have become available in 52.0 and not in ealier version (!?) according to the following URL.

https://developer.mozilla.org/en-US/docs/Mozilla/Debugging/HTTP_logging

(In reply to ISHIKAWA, Chiaki from comment #19)

(In reply to Karl Tomlinson (:karlt) from comment #7)

https://mozilla.github.io/mozregression/ can work with Thunderbird, but I'd guess this is easier to reproduce in Firefox with data:text/html,<textarea>

Comparing output before and after the regression with MOZ_LOG=nsGtkIMModuleWidgets:5 in the environment may be helpful.

I doubt this is related to bug 787943.

Hmm... Does this MOZ_LOG thing work only with a debug version?
Nothing is printed with 47.0.1.
I will investigate.

Use NS_LOG_MODULES instead of MOZ_LOG, and NS_LOG_FILE instead of MOZ_LOG_FILE. (Different from MOZ_LOG, ,sync isn't necessary to use.)

(In reply to Masayuki Nakano [:masayuki] (JST, +0900) from comment #21)

...

Use NS_LOG_MODULES instead of MOZ_LOG, and NS_LOG_FILE instead of MOZ_LOG_FILE. (Different from MOZ_LOG, ,sync isn't necessary to use.)

Turns out the proper environemt variables for firefox 47.0.1 and 48.0.1 are
export NSPR_LOG_FILE=/tmp/t.log
export NSPR_LOG_MODULES=nsGtkIMModuleWidgets:5

In the end, I ran the following to look for possible variable names.
strings - firefox-47/firefox/libxul.so | grep _LOG

Anyway, I am uploading the log from a very simple run.
It is a bit difficult to create exactly the same events since the lack of visual feedback makes it a bit awkward to operate on the FF 48 version.

This is obtained using firefox 47.0.1:
I ran firefox binary with the following setting.

export NSPR_LOG_FILE=/tmp/t.log
export NSPR_LOG_MODULES=nsGtkIMModuleWidgets:5

I invoked Japanese input using kinput2-wnn by hitting control-space, and
then typed
touyoudaigaku
and then hit another space
to start the selection of kana-kanji conversion candidate, and
then finalize the choice by hitting ENTER
and then quit.

(There may be extra keystrokes or mouse movement. I realize that when I perform
Japanese input, some conversion-related key inputs are done subconciously after all these years.)

This is recorded in a similar manner as in the previous upload of
9049780: Japanese Input Event log from firefox 47.0.1 - expected correct case

In this case, however, when I hit the space after typing touyoudaigaku
I do not get the visual feedback, i.e., the underlined とうようだいがく　string does not get shown as the converted kanji string (which I am sure that the internal conversion processing has performed since when I hit return/enter at the end, I get the converted string. So the problem is that proper display updating or repainting does not occur.)

TIA

I think I found one possible culprit. There may be others, but one fix at a time.

SetCursorPosition events seem to be generated with incorrect string length. Note the
lines below where BUG? is inserted.
(Then later I found all the SetCurosorPosition events are generated with this bogus length, but please read the entire comment since there are two instances where this bogus value is used even in the case of correct FF 47.0.1 behavior.)

I have yet to figure out where this is related in the patch mentioned here.

Otherwise, I cannot seem to find the problem of no visual feedback.
It is possible that an outrageous value of string length screws up the
graphics portion of GDK.

===

Comparison of the relevant portion of the log to see where one anomaly is.

The follwing is from ff 47.0.1, the working case.

Explanation:
I typed upto touyoudaigaku to obtain とうようだいがく. And the log follows with my annotation lines that starts with "*" at the beginning of the line.

Note: There may be a few asynchronous/intermixed events for key press/release: I seem to release key a bit late after the next key pressing.)
E.g.:
pressking 'k' (not quoted here. happens several events before.)
pressing 'u'
releasing 'k'
releasing 'u'

Here is the annotated log.

*I hit u to obtain とうようだいがく GDK_KEY_PRESS with keyval=u

1508099904[7f7959c9b460]: GTKIM: 7f7941035760 OnKeyEvent(aCaller=7f79412f8400, aKeyDownEventWasSent=false), mCompositionState=CompositionChangeEventDispatched, current context=7f794102a530, active context=7f794102a530, aEvent(7f792935fce0): { type=GDK_KEY_PRESS, keyval=u, unicode=0x75 }
1508099904[7f7959c9b460]: GTKIM: 7f7941035760 OnChangeCompositionNative(aContext=7f794102a530)
1508099904[7f7959c9b460]: GTKIM: 7f7941035760 GetCompositionString(aContext=7f794102a530), aCompositionString="とうようだいがく"
1508099904[7f7959c9b460]: GTKIM: 7f7941035760 DispatchCompositionChangeEvent(aContext=7f794102a530)
1508099904[7f7959c9b460]: GTKIM: 7f7941035760 CreateTextRangeArray(aContext=7f794102a530, aCompositionString="とうようだいがく" (Length()=8))
1508099904[7f7959c9b460]: GTKIM: 7f7941035760 SetTextRange(), succeeded, aTextRange= { mStartOffset=0, mEndOffset=8, mRangeType=NS_TEXTRANGE_RAWINPUT, mRangeStyle={ mLineStyle=LINESTYLE_SOLID, IsUnderlineColorDefined=false, IsForegroundColorDefined()=false, IsBackgroundColorDefined()=false } }
1508099904[7f7959c9b460]: GTKIM: 7f7941035760 SetTextRange(), FAILED, due to no attr, aTextRange= { mStartOffset=8, mEndOffset=8 }
1508099904[7f7959c9b460]: GTKIM: 7f7941035760 CreateTextRangeArray(), mStartOffset=8, mEndOffset=8, mRangeType=NS_TEXTRANGE_CARETPOSITION
1508099904[7f7959c9b460]: GTKIM: 7f7941035760 SetCursorPosition(aContext=7f794102a530), mCompositionTargetRange={ mOffset=0, mLength=8 }mSelection={ mOffset=0, mLength=0, mWritingMode=Horizontal }
1508099904[7f7959c9b460]: GTKIM: 7f7941035760 SetCursorPosition(aContext=7f794102a530), mCompositionTargetRange={ mOffset=0, mLength=8 }mSelection={ mOffset=0, mLength=0, mWritingMode=Horizontal }
1508099904[7f7959c9b460]: GTKIM: 7f7941035760 OnKeyEvent(), succeeded, filterThisEvent=true (isFiltered=true, mFilterKeyEvent=true), mCompositionState=CompositionChangeEventDispatched

*Release of formerly pressed 'k' GDK_KEY_RELEASE with keyval=k

• (I seem to release the key a bit late. This happens AFTER the pressing of 'u' in "touyoudaigaku" at the end.

1508099904[7f7959c9b460]: GTKIM: 7f7941035760 OnKeyEvent(aCaller=7f79412f8400, aKeyDownEventWasSent=false), mCompositionState=CompositionChangeEventDispatched, current context=7f794102a530, active context=7f794102a530, aEvent(7f79365ae840): { type=GDK_KEY_RELEASE, keyval=k, unicode=0x6B }
1508099904[7f7959c9b460]: GTKIM: 7f7941035760 OnKeyEvent(), succeeded, filterThisEvent=true (isFiltered=true, mFilterKeyEvent=true), mCompositionState=CompositionChangeEventDispatched
1508099904[7f7959c9b460]: GTKIM: 7f7941035760 SetCursorPosition(aContext=7f794102a530), mCompositionTargetRange={ mOffset=0, mLength=8 }mSelection={ mOffset=0, mLength=0, mWritingMode=Horizontal }

*Release of pressed 'u' GDK_KEY_RELEASE with keyval=u

1508099904[7f7959c9b460]: GTKIM: 7f7941035760 OnKeyEvent(aCaller=7f79412f8400, aKeyDownEventWasSent=false), mCompositionState=CompositionChangeEventDispatched, current context=7f794102a530, active context=7f794102a530, aEvent(7f7929582020): { type=GDK_KEY_RELEASE, keyval=u, unicode=0x75 }
1508099904[7f7959c9b460]: GTKIM: 7f7941035760 OnKeyEvent(), succeeded, filterThisEvent=true (isFiltered=true, mFilterKeyEvent=true), mCompositionState=CompositionChangeEventDispatched

*Start kana-kanji conversion with space: GDK_KEY_PRESS, keyval=space

• I get the desired string 東洋大学 on the first conversion. Lucky me.

1508099904[7f7959c9b460]: GTKIM: 7f7941035760 OnKeyEvent(aCaller=7f79412f8400, aKeyDownEventWasSent=false), mCompositionState=CompositionChangeEventDispatched, current context=7f794102a530, active context=7f794102a530, aEvent(7f7929582020): { type=GDK_KEY_PRESS, keyval=space, unicode=0x20 }
1508099904[7f7959c9b460]: GTKIM: 7f7941035760 OnChangeCompositionNative(aContext=7f794102a530)
1508099904[7f7959c9b460]: GTKIM: 7f7941035760 GetCompositionString(aContext=7f794102a530), aCompositionString="東洋大学"
1508099904[7f7959c9b460]: GTKIM: 7f7941035760 DispatchCompositionChangeEvent(aContext=7f794102a530)
1508099904[7f7959c9b460]: GTKIM: 7f7941035760 CreateTextRangeArray(aContext=7f794102a530, aCompositionString="東洋大学" (Length()=4))
1508099904[7f7959c9b460]: GTKIM: 7f7941035760 SetTextRange(), succeeded, aTextRange= { mStartOffset=0, mEndOffset=2, mRangeType=NS_TEXTRANGE_CONVERTEDTEXT, mRangeStyle={ mLineStyle=LINESTYLE_NONE, IsUnderlineColorDefined=false, mForegroundColor={ R=0xFF, G=0xFF, B=0xFF, A=0xFF }, mBackgroundColor={ R=0x00, G=0x00, B=0x00, A=0xFF } } }
1508099904[7f7959c9b460]: GTKIM: 7f7941035760 SetTextRange(), FAILED, due to no attr, aTextRange= { mStartOffset=2, mEndOffset=4 }
1508099904[7f7959c9b460]: GTKIM: 7f7941035760 CreateTextRangeArray(), mStartOffset=4, mEndOffset=4, mRangeType=NS_TEXTRANGE_CARETPOSITION
1508099904[7f7959c9b460]: GTKIM: 7f7941035760 SetCursorPosition(aContext=7f794102a530), mCompositionTargetRange={ mOffset=0, mLength=4 }mSelection={ mOffset=0, mLength=0, mWritingMode=Horizontal }
1508099904[7f7959c9b460]: GTKIM: 7f7941035760 SetCursorPosition(aContext=7f794102a530), mCompositionTargetRange={ mOffset=0, mLength=4 }mSelection={ mOffset=0, mLength=0, mWritingMode=Horizontal }
1508099904[7f7959c9b460]: GTKIM: 7f7941035760 OnKeyEvent(), succeeded, filterThisEvent=true (isFiltered=true, mFilterKeyEvent=true), mCompositionState=CompositionChangeEventDispatched

So far, so good.

In comparison, the following is from ff 48.0.1, the regressed behavior:

*I hit u to obtain とうようだいがく GDK_KEY_PRESS with keyval=u

1952245568[7fef7439b460]: GTKIM: 7fef5b8c9de0 OnKeyEvent(aCaller=7fef5b6a1800, aKeyDownEventWasSent=false), mCompositionState=CompositionChangeEventDispatched, current context=7fef5b696df0, active context=7fef5b696df0, aEvent(7fef468f5e80): { type=GDK_KEY_PRESS, keyval=u, unicode=0x75 }
1952245568[7fef7439b460]: GTKIM: 7fef5b8c9de0 OnChangeCompositionNative(aContext=7fef5b696df0)
1952245568[7fef7439b460]: GTKIM: 7fef5b8c9de0 GetCompositionString(aContext=7fef5b696df0), aCompositionString="とうようだいがく"
1952245568[7fef7439b460]: GTKIM: 7fef5b8c9de0 DispatchCompositionChangeEvent(aContext=7fef5b696df0)
1952245568[7fef7439b460]: GTKIM: 7fef5b8c9de0 CreateTextRangeArray(aContext=7fef5b696df0, aCompositionString="とうようだいがく" (Length()=8))
1952245568[7fef7439b460]: GTKIM: 7fef5b8c9de0 SetTextRange(), succeeded, aTextRange= { mStartOffset=0, mEndOffset=8, mRangeType=NS_TEXTRANGE_RAWINPUT, mRangeStyle={ mLineStyle=LINESTYLE_SOLID, IsUnderlineColorDefined=false, IsForegroundColorDefined()=false, IsBackgroundColorDefined()=false } }
1952245568[7fef7439b460]: GTKIM: 7fef5b8c9de0 SetTextRange(), FAILED, due to no attr, aTextRange= { mStartOffset=8, mEndOffset=8 }
1952245568[7fef7439b460]: GTKIM: 7fef5b8c9de0 CreateTextRangeArray(), mStartOffset=8, mEndOffset=8, mRangeType=NS_TEXTRANGE_CARETPOSITION

BUG?
*SOMETHING IS WRONG in the following line: Note the outrageously large mLength value (!)

• mLength=4294967295 which is 0xFFFFFFFF.
• Maybe this was set to (-1) and never gets properly initialized?

1952245568[7fef7439b460]: GTKIM: 7fef5b8c9de0 SetCursorPosition(aContext=7fef5b696df0), mCompositionTargetRange={ mOffset=0, mLength=4294967295 }mSelection={ mOffset=0, mLength=0, mWritingMode=Horizontal }
1952245568[7fef7439b460]: GTKIM: 7fef5b8c9de0 SetCursorPosition(aContext=7fef5b696df0), mCompositionTargetRange={ mOffset=0, mLength=4294967295 }mSelection={ mOffset=0, mLength=0, mWritingMode=Horizontal }
1952245568[7fef7439b460]: GTKIM: 7fef5b8c9de0 OnKeyEvent(), succeeded, filterThisEvent=true (isFiltered=true, mFilterKeyEvent=true), mCompositionState=CompositionChangeEventDispatched

*Release of formerly pressed 'k' GDK_KEY_RELEASE with keyval=k

• (I seem to release the key a bit late. This happens AFTER the pressing of 'u' in "touyoudaigaku" at the end.

1952245568[7fef7439b460]: GTKIM: 7fef5b8c9de0 OnKeyEvent(aCaller=7fef5b6a1800, aKeyDownEventWasSent=false), mCompositionState=CompositionChangeEventDispatched, current context=7fef5b696df0, active context=7fef5b696df0, aEvent(7fef4185cca0): { type=GDK_KEY_RELEASE, keyval=k, unicode=0x6B }
1952245568[7fef7439b460]: GTKIM: 7fef5b8c9de0 OnKeyEvent(), succeeded, filterThisEvent=true (isFiltered=true, mFilterKeyEvent=true), mCompositionState=CompositionChangeEventDispatched

BUG?

• SOMETHING IS WRONG in the following line: Note the outrageously large mLength value (!)
• mLength=4294967295 which is 0xFFFFFFFF.
• Maybe this was set to (-1) and never gets properly initialized?

1952245568[7fef7439b460]: GTKIM: 7fef5b8c9de0 SetCursorPosition(aContext=7fef5b696df0), mCompositionTargetRange={ mOffset=0, mLength=4294967295 }mSelection={ mOffset=0, mLength=0, mWritingMode=Horizontal }

*Release of pressed 'u' GDK_KEY_RELEASE with keyval=u
1952245568[7fef7439b460]: GTKIM: 7fef5b8c9de0 OnKeyEvent(aCaller=7fef5b6a1800, aKeyDownEventWasSent=false), mCompositionState=CompositionChangeEventDispatched, current context=7fef5b696df0, active context=7fef5b696df0, aEvent(7fef41a482a0): { type=GDK_KEY_RELEASE, keyval=u, unicode=0x75 }
1952245568[7fef7439b460]: GTKIM: 7fef5b8c9de0 OnKeyEvent(), succeeded, filterThisEvent=true (isFiltered=true, mFilterKeyEvent=true), mCompositionState=CompositionChangeEventDispatched

*Start kana-kanji conversion with space: GDK_KEY_PRESS, keyval=space
*Note that the candidate string is different: this is probably due to the "LEARNING" of conversion server or something.
*But I could be wrong.
1952245568[7fef7439b460]: GTKIM: 7fef5b8c9de0 OnKeyEvent(aCaller=7fef5b6a1800, aKeyDownEventWasSent=false), mCompositionState=CompositionChangeEventDispatched, current context=7fef5b696df0, active context=7fef5b696df0, aEvent(7fef4185cc00): { type=GDK_KEY_PRESS, keyval=space, unicode=0x20 }
1952245568[7fef7439b460]: GTKIM: 7fef5b8c9de0 OnChangeCompositionNative(aContext=7fef5b696df0)
1952245568[7fef7439b460]: GTKIM: 7fef5b8c9de0 GetCompositionString(aContext=7fef5b696df0), aCompositionString="登庸大学"
1952245568[7fef7439b460]: GTKIM: 7fef5b8c9de0 DispatchCompositionChangeEvent(aContext=7fef5b696df0)
1952245568[7fef7439b460]: GTKIM: 7fef5b8c9de0 CreateTextRangeArray(aContext=7fef5b696df0, aCompositionString="登庸大学" (Length()=4))
1952245568[7fef7439b460]: GTKIM: 7fef5b8c9de0 SetTextRange(), succeeded, aTextRange= { mStartOffset=0, mEndOffset=2, mRangeType=NS_TEXTRANGE_CONVERTEDTEXT, mRangeStyle={ mLineStyle=LINESTYLE_NONE, IsUnderlineColorDefined=false, mForegroundColor={ R=0xFF, G=0xFF, B=0xFF, A=0xFF }, mBackgroundColor={ R=0x00, G=0x00, B=0x00, A=0xFF } } }

Analysis:

Upon further investigation, all SetCursorPosition evnents are generated with mLength=4294967295 (-1) in the case of regressed firefox 48 run.

However, do note that there ARE instances of such SetCursorPosition event in the case of firefox 47 run (correct case).
It seems at the beginning and end of conversion, SetCursorPosition event with the following setting mCompositionTargetRange {mOffset=4294967295, mLength=4294967295}. The first event, though, has mSelection={ mOffset=4294967295, mLength=4294967295, mWritingMode=Horizontal }, and the last SetCursorPosition event has mSelection={ mOffset=4, mLength=0, mWritingMode=Horizontal } (This probably refers to the fact that the processing is past the four characters "東洋大学".)

From firefox 47 log.

...
1508099904[7f7959c9b460]: GTKIM: 7f7941035760 SetCursorPosition(aContext=7f794102a530), mCompositionTargetRange={ mOffset=4294967295, mLength=4294967295 }mSelection={ mOffset=4294967295, mLength=4294967295, mWritingMode=Horizontal }
1508099904[7f7959c9b460]: GTKIM: 7f7941035760 SetCursorPosition(), FAILED, mCompositionTargetRange and mSelection are invalid
...
...
...
1508099904[7f7959c9b460]: GTKIM: 7f7941035760 SetCursorPosition(aContext=7f794102a530), mCompositionTargetRange={ mOffset=4294967295, mLength=4294967295 }mSelection={ mOffset=4, mLength=0, mWritingMode=Horizontal }
1508099904[7f7959c9b460]: GTKIM: 7f7941035760 OnKeyEvent(), succeeded, filterThisEvent=true (isFiltered=true, mFilterKeyEvent=true), mCompositionState=NotComposing
1508099904[7f7959c9b460]: GTKIM: 7f7941035760 SetInputContext(aCaller=7f79412f8400, aContext={ mIMEState={ mEnabled=DISABLED }, mHTMLInputType=text })
1508099904[7f7959c9b460]: GTKIM: 7f7941035760 EndIMEComposition(aCaller=7f79412f8400), mCompositionState=NotComposing

From firefox 48 log:

,,,
1952245568[7fef7439b460]: GTKIM: 7fef5b8c9de0 SetCursorPosition(aContext=7fef5b696df0), mCompositionTargetRange={ mOffset=4294967295, mLength=4294967295 }mSelection={ mOffset=4294967295, mLength=4294967295, mWritingMode=Horizontal }
1952245568[7fef7439b460]: GTKIM: 7fef5b8c9de0 SetCursorPosition(), FAILED, mCompositionTargetRange and mSelection are invalid
...
... many SetCursorPosition events with incorrect mLength=mLength=4294967295
...
1952245568[7fef7439b460]: GTKIM: 7fef5b8c9de0 SetCursorPosition(aContext=7fef5b696df0), mCompositionTargetRange={ mOffset=4294967295, mLength=4294967295 }mSelection={ mOffset=4, mLength=0, mWritingMode=Horizontal }
1952245568[7fef7439b460]: GTKIM: 7fef5b8c9de0 OnKeyEvent(), succeeded, filterThisEvent=true (isFiltered=true, mFilterKeyEvent=true), mCompositionState=NotComposing
1952245568[7fef7439b460]: GTKIM: 7fef5b8c9de0 OnBlurWindow(aWindow=7fef5b6a1800), mLastFocusedWindow=7fef5b6a1800, mIsIMFocused=true
1952245568[7fef7439b460]: GTKIM: 7fef5b8c9de0 Blur(), mIsIMFocused=true
1952245568[7fef7439b460]: GTKIM: 7fef5b8c9de0 OnFocusChangeInGecko(aFocus=false), mCompositionState=NotComposing, mIsIMFocused=false

I think there may be other bugs that may become clear once this bogus mLength issued is fixed.
There are some inconsistencies between the values of mSelection between ff 47.0.1 and 48.0.1 version, but I am not sure if they are the result of bogus mLength or due to different bugs.

Hope this helps.

FYI,
this is the list of appearances of SetCursorPosition in ff 47.0.1 log.

SetCursorPosition(aContext=7f794102a530), mCompositionTargetRange={ mOffset=4294967295, mLength=4294967295 }mSelection={ mOffset=4294967295, mLength=4294967295, mWritingMode=Horizontal }
SetCursorPosition(), FAILED, mCompositionTargetRange and mSelection are invalid
SetCursorPosition(aContext=7f794102a530), mCompositionTargetRange={ mOffset=0, mLength=1 }mSelection={ mOffset=0, mLength=0, mWritingMode=Horizontal }
SetCursorPosition(aContext=7f794102a530), mCompositionTargetRange={ mOffset=0, mLength=1 }mSelection={ mOffset=0, mLength=0, mWritingMode=Horizontal }
SetCursorPosition(aContext=7f794102a530), mCompositionTargetRange={ mOffset=0, mLength=1 }mSelection={ mOffset=0, mLength=0, mWritingMode=Horizontal }
SetCursorPosition(aContext=7f794102a530), mCompositionTargetRange={ mOffset=0, mLength=1 }mSelection={ mOffset=0, mLength=0, mWritingMode=Horizontal }
SetCursorPosition(aContext=7f794102a530), mCompositionTargetRange={ mOffset=0, mLength=1 }mSelection={ mOffset=0, mLength=0, mWritingMode=Horizontal }
SetCursorPosition(aContext=7f794102a530), mCompositionTargetRange={ mOffset=0, mLength=1 }mSelection={ mOffset=0, mLength=0, mWritingMode=Horizontal }
SetCursorPosition(aContext=7f794102a530), mCompositionTargetRange={ mOffset=0, mLength=2 }mSelection={ mOffset=0, mLength=0, mWritingMode=Horizontal }
SetCursorPosition(aContext=7f794102a530), mCompositionTargetRange={ mOffset=0, mLength=2 }mSelection={ mOffset=0, mLength=0, mWritingMode=Horizontal }
SetCursorPosition(aContext=7f794102a530), mCompositionTargetRange={ mOffset=0, mLength=2 }mSelection={ mOffset=0, mLength=0, mWritingMode=Horizontal }
SetCursorPosition(aContext=7f794102a530), mCompositionTargetRange={ mOffset=0, mLength=3 }mSelection={ mOffset=0, mLength=0, mWritingMode=Horizontal }
SetCursorPosition(aContext=7f794102a530), mCompositionTargetRange={ mOffset=0, mLength=3 }mSelection={ mOffset=0, mLength=0, mWritingMode=Horizontal }
SetCursorPosition(aContext=7f794102a530), mCompositionTargetRange={ mOffset=0, mLength=3 }mSelection={ mOffset=0, mLength=0, mWritingMode=Horizontal }
SetCursorPosition(aContext=7f794102a530), mCompositionTargetRange={ mOffset=0, mLength=3 }mSelection={ mOffset=0, mLength=0, mWritingMode=Horizontal }
SetCursorPosition(aContext=7f794102a530), mCompositionTargetRange={ mOffset=0, mLength=4 }mSelection={ mOffset=0, mLength=0, mWritingMode=Horizontal }
SetCursorPosition(aContext=7f794102a530), mCompositionTargetRange={ mOffset=0, mLength=4 }mSelection={ mOffset=0, mLength=0, mWritingMode=Horizontal }
SetCursorPosition(aContext=7f794102a530), mCompositionTargetRange={ mOffset=0, mLength=4 }mSelection={ mOffset=0, mLength=0, mWritingMode=Horizontal }
SetCursorPosition(aContext=7f794102a530), mCompositionTargetRange={ mOffset=0, mLength=5 }mSelection={ mOffset=0, mLength=0, mWritingMode=Horizontal }
SetCursorPosition(aContext=7f794102a530), mCompositionTargetRange={ mOffset=0, mLength=5 }mSelection={ mOffset=0, mLength=0, mWritingMode=Horizontal }
SetCursorPosition(aContext=7f794102a530), mCompositionTargetRange={ mOffset=0, mLength=5 }mSelection={ mOffset=0, mLength=0, mWritingMode=Horizontal }
SetCursorPosition(aContext=7f794102a530), mCompositionTargetRange={ mOffset=0, mLength=5 }mSelection={ mOffset=0, mLength=0, mWritingMode=Horizontal }
SetCursorPosition(aContext=7f794102a530), mCompositionTargetRange={ mOffset=0, mLength=5 }mSelection={ mOffset=0, mLength=0, mWritingMode=Horizontal }
SetCursorPosition(aContext=7f794102a530), mCompositionTargetRange={ mOffset=0, mLength=5 }mSelection={ mOffset=0, mLength=0, mWritingMode=Horizontal }
SetCursorPosition(aContext=7f794102a530), mCompositionTargetRange={ mOffset=0, mLength=6 }mSelection={ mOffset=0, mLength=0, mWritingMode=Horizontal }
SetCursorPosition(aContext=7f794102a530), mCompositionTargetRange={ mOffset=0, mLength=6 }mSelection={ mOffset=0, mLength=0, mWritingMode=Horizontal }
SetCursorPosition(aContext=7f794102a530), mCompositionTargetRange={ mOffset=0, mLength=6 }mSelection={ mOffset=0, mLength=0, mWritingMode=Horizontal }
SetCursorPosition(aContext=7f794102a530), mCompositionTargetRange={ mOffset=0, mLength=7 }mSelection={ mOffset=0, mLength=0, mWritingMode=Horizontal }
SetCursorPosition(aContext=7f794102a530), mCompositionTargetRange={ mOffset=0, mLength=7 }mSelection={ mOffset=0, mLength=0, mWritingMode=Horizontal }
SetCursorPosition(aContext=7f794102a530), mCompositionTargetRange={ mOffset=0, mLength=7 }mSelection={ mOffset=0, mLength=0, mWritingMode=Horizontal }
SetCursorPosition(aContext=7f794102a530), mCompositionTargetRange={ mOffset=0, mLength=7 }mSelection={ mOffset=0, mLength=0, mWritingMode=Horizontal }
SetCursorPosition(aContext=7f794102a530), mCompositionTargetRange={ mOffset=0, mLength=7 }mSelection={ mOffset=0, mLength=0, mWritingMode=Horizontal }
SetCursorPosition(aContext=7f794102a530), mCompositionTargetRange={ mOffset=0, mLength=8 }mSelection={ mOffset=0, mLength=0, mWritingMode=Horizontal }
SetCursorPosition(aContext=7f794102a530), mCompositionTargetRange={ mOffset=0, mLength=8 }mSelection={ mOffset=0, mLength=0, mWritingMode=Horizontal }
SetCursorPosition(aContext=7f794102a530), mCompositionTargetRange={ mOffset=0, mLength=8 }mSelection={ mOffset=0, mLength=0, mWritingMode=Horizontal }
SetCursorPosition(aContext=7f794102a530), mCompositionTargetRange={ mOffset=0, mLength=8 }mSelection={ mOffset=0, mLength=0, mWritingMode=Horizontal }
SetCursorPosition(aContext=7f794102a530), mCompositionTargetRange={ mOffset=0, mLength=8 }mSelection={ mOffset=0, mLength=0, mWritingMode=Horizontal }
SetCursorPosition(aContext=7f794102a530), mCompositionTargetRange={ mOffset=0, mLength=8 }mSelection={ mOffset=0, mLength=0, mWritingMode=Horizontal }
SetCursorPosition(aContext=7f794102a530), mCompositionTargetRange={ mOffset=0, mLength=4 }mSelection={ mOffset=0, mLength=0, mWritingMode=Horizontal }
SetCursorPosition(aContext=7f794102a530), mCompositionTargetRange={ mOffset=0, mLength=4 }mSelection={ mOffset=0, mLength=0, mWritingMode=Horizontal }
SetCursorPosition(aContext=7f794102a530), mCompositionTargetRange={ mOffset=0, mLength=4 }mSelection={ mOffset=0, mLength=0, mWritingMode=Horizontal }
SetCursorPosition(aContext=7f794102a530), mCompositionTargetRange={ mOffset=0, mLength=0 }mSelection={ mOffset=0, mLength=0, mWritingMode=Horizontal }
SetCursorPosition(aContext=7f794102a530), mCompositionTargetRange={ mOffset=0, mLength=0 }mSelection={ mOffset=0, mLength=0, mWritingMode=Horizontal }
SetCursorPosition(aContext=7f794102a530), mCompositionTargetRange={ mOffset=4294967295, mLength=4294967295 }mSelection={ mOffset=4, mLength=0, mWritingMode=Horizontal }

This is the list of appearances of SetCursorPosition in ff 48.0.1 log.

SetCursorPosition(aContext=7fef5b696df0), mCompositionTargetRange={ mOffset=4294967295, mLength=4294967295 }mSelection={ mOffset=4294967295, mLength=4294967295, mWritingMode=Horizontal }
SetCursorPosition(), FAILED, mCompositionTargetRange and mSelection are invalid
SetCursorPosition(aContext=7fef5b696df0), mCompositionTargetRange={ mOffset=0, mLength=4294967295 }mSelection={ mOffset=0, mLength=0, mWritingMode=Horizontal }
SetCursorPosition(aContext=7fef5b696df0), mCompositionTargetRange={ mOffset=0, mLength=4294967295 }mSelection={ mOffset=0, mLength=0, mWritingMode=Horizontal }
SetCursorPosition(aContext=7fef5b696df0), mCompositionTargetRange={ mOffset=0, mLength=4294967295 }mSelection={ mOffset=0, mLength=0, mWritingMode=Horizontal }
SetCursorPosition(aContext=7fef5b696df0), mCompositionTargetRange={ mOffset=0, mLength=4294967295 }mSelection={ mOffset=0, mLength=0, mWritingMode=Horizontal }
SetCursorPosition(aContext=7fef5b696df0), mCompositionTargetRange={ mOffset=0, mLength=4294967295 }mSelection={ mOffset=0, mLength=0, mWritingMode=Horizontal }
SetCursorPosition(aContext=7fef5b696df0), mCompositionTargetRange={ mOffset=0, mLength=4294967295 }mSelection={ mOffset=0, mLength=0, mWritingMode=Horizontal }
SetCursorPosition(aContext=7fef5b696df0), mCompositionTargetRange={ mOffset=0, mLength=4294967295 }mSelection={ mOffset=0, mLength=0, mWritingMode=Horizontal }
SetCursorPosition(aContext=7fef5b696df0), mCompositionTargetRange={ mOffset=0, mLength=4294967295 }mSelection={ mOffset=0, mLength=0, mWritingMode=Horizontal }
SetCursorPosition(aContext=7fef5b696df0), mCompositionTargetRange={ mOffset=0, mLength=4294967295 }mSelection={ mOffset=0, mLength=0, mWritingMode=Horizontal }
SetCursorPosition(aContext=7fef5b696df0), mCompositionTargetRange={ mOffset=0, mLength=4294967295 }mSelection={ mOffset=0, mLength=0, mWritingMode=Horizontal }
SetCursorPosition(aContext=7fef5b696df0), mCompositionTargetRange={ mOffset=0, mLength=4294967295 }mSelection={ mOffset=0, mLength=0, mWritingMode=Horizontal }
SetCursorPosition(aContext=7fef5b696df0), mCompositionTargetRange={ mOffset=0, mLength=4294967295 }mSelection={ mOffset=0, mLength=0, mWritingMode=Horizontal }
SetCursorPosition(aContext=7fef5b696df0), mCompositionTargetRange={ mOffset=0, mLength=4294967295 }mSelection={ mOffset=0, mLength=0, mWritingMode=Horizontal }
SetCursorPosition(aContext=7fef5b696df0), mCompositionTargetRange={ mOffset=0, mLength=4294967295 }mSelection={ mOffset=0, mLength=0, mWritingMode=Horizontal }
SetCursorPosition(aContext=7fef5b696df0), mCompositionTargetRange={ mOffset=0, mLength=4294967295 }mSelection={ mOffset=0, mLength=0, mWritingMode=Horizontal }
SetCursorPosition(aContext=7fef5b696df0), mCompositionTargetRange={ mOffset=0, mLength=4294967295 }mSelection={ mOffset=0, mLength=0, mWritingMode=Horizontal }
SetCursorPosition(aContext=7fef5b696df0), mCompositionTargetRange={ mOffset=0, mLength=4294967295 }mSelection={ mOffset=0, mLength=0, mWritingMode=Horizontal }
SetCursorPosition(aContext=7fef5b696df0), mCompositionTargetRange={ mOffset=0, mLength=4294967295 }mSelection={ mOffset=0, mLength=0, mWritingMode=Horizontal }
SetCursorPosition(aContext=7fef5b696df0), mCompositionTargetRange={ mOffset=0, mLength=4294967295 }mSelection={ mOffset=0, mLength=0, mWritingMode=Horizontal }
SetCursorPosition(aContext=7fef5b696df0), mCompositionTargetRange={ mOffset=0, mLength=4294967295 }mSelection={ mOffset=0, mLength=0, mWritingMode=Horizontal }
SetCursorPosition(aContext=7fef5b696df0), mCompositionTargetRange={ mOffset=0, mLength=4294967295 }mSelection={ mOffset=0, mLength=0, mWritingMode=Horizontal }
SetCursorPosition(aContext=7fef5b696df0), mCompositionTargetRange={ mOffset=0, mLength=4294967295 }mSelection={ mOffset=0, mLength=0, mWritingMode=Horizontal }
SetCursorPosition(aContext=7fef5b696df0), mCompositionTargetRange={ mOffset=0, mLength=4294967295 }mSelection={ mOffset=0, mLength=0, mWritingMode=Horizontal }
SetCursorPosition(aContext=7fef5b696df0), mCompositionTargetRange={ mOffset=0, mLength=4294967295 }mSelection={ mOffset=0, mLength=0, mWritingMode=Horizontal }
SetCursorPosition(aContext=7fef5b696df0), mCompositionTargetRange={ mOffset=0, mLength=4294967295 }mSelection={ mOffset=0, mLength=0, mWritingMode=Horizontal }
SetCursorPosition(aContext=7fef5b696df0), mCompositionTargetRange={ mOffset=0, mLength=4294967295 }mSelection={ mOffset=0, mLength=0, mWritingMode=Horizontal }
SetCursorPosition(aContext=7fef5b696df0), mCompositionTargetRange={ mOffset=0, mLength=4294967295 }mSelection={ mOffset=0, mLength=0, mWritingMode=Horizontal }
SetCursorPosition(aContext=7fef5b696df0), mCompositionTargetRange={ mOffset=0, mLength=4294967295 }mSelection={ mOffset=0, mLength=0, mWritingMode=Horizontal }
SetCursorPosition(aContext=7fef5b696df0), mCompositionTargetRange={ mOffset=0, mLength=4294967295 }mSelection={ mOffset=0, mLength=0, mWritingMode=Horizontal }
SetCursorPosition(aContext=7fef5b696df0), mCompositionTargetRange={ mOffset=0, mLength=4294967295 }mSelection={ mOffset=0, mLength=0, mWritingMode=Horizontal }
SetCursorPosition(aContext=7fef5b696df0), mCompositionTargetRange={ mOffset=0, mLength=4294967295 }mSelection={ mOffset=0, mLength=0, mWritingMode=Horizontal }
SetCursorPosition(aContext=7fef5b696df0), mCompositionTargetRange={ mOffset=0, mLength=4294967295 }mSelection={ mOffset=0, mLength=0, mWritingMode=Horizontal }
SetCursorPosition(aContext=7fef5b696df0), mCompositionTargetRange={ mOffset=0, mLength=4294967295 }mSelection={ mOffset=0, mLength=0, mWritingMode=Horizontal }
SetCursorPosition(aContext=7fef5b696df0), mCompositionTargetRange={ mOffset=0, mLength=4294967295 }mSelection={ mOffset=0, mLength=0, mWritingMode=Horizontal }
SetCursorPosition(aContext=7fef5b696df0), mCompositionTargetRange={ mOffset=0, mLength=4294967295 }mSelection={ mOffset=0, mLength=0, mWritingMode=Horizontal }
SetCursorPosition(aContext=7fef5b696df0), mCompositionTargetRange={ mOffset=0, mLength=4294967295 }mSelection={ mOffset=0, mLength=0, mWritingMode=Horizontal }
SetCursorPosition(aContext=7fef5b696df0), mCompositionTargetRange={ mOffset=0, mLength=4294967295 }mSelection={ mOffset=0, mLength=0, mWritingMode=Horizontal }
SetCursorPosition(aContext=7fef5b696df0), mCompositionTargetRange={ mOffset=0, mLength=4294967295 }mSelection={ mOffset=0, mLength=0, mWritingMode=Horizontal }
SetCursorPosition(aContext=7fef5b696df0), mCompositionTargetRange={ mOffset=0, mLength=4294967295 }mSelection={ mOffset=0, mLength=0, mWritingMode=Horizontal }
SetCursorPosition(aContext=7fef5b696df0), mCompositionTargetRange={ mOffset=4294967295, mLength=4294967295 }mSelection={ mOffset=4, mLength=0, mWritingMode=Horizontal }

There is a place in the changeset where mLength seems to be assigned directly.

https://hg.mozilla.org/mozilla-central/rev/341344bdec8f#l487.238

Excerpt: (OK I have recalled now how to blockqoute code. )

     mCompositionState = eCompositionState_CompositionChangeEventDispatched;
 
     // We cannot call SetCursorPosition for e10s-aware.
     // DispatchEvent is async on e10s, so composition rect isn't updated now
     // on tab parent.
+    mDispatchedCompositionString = aCompositionString;
     mLayoutChanged = false;
-    mCompositionTargetRange.mOffset = targetOffset;
-    mCompositionTargetRange.mLength =
-        compositionChangeEvent.TargetClauseLength();
+    mCompositionTargetRange.mOffset = rangeArray->TargetClauseOffset();
+    mCompositionTargetRange.mLength = rangeArray->TargetClauseLength();  <=== THIS LINE

But I have no idea how rangeArray is constructed, etc.
Maybe we need to use history-sensitive information to get the value correctly (especially on the first and second events after the a new Japanese input sequence starts?)

This is all I can offer for today.

One more thing:

 // We cannot call SetCursorPosition for e10s-aware.
     // DispatchEvent is async on e10s, so composition rect isn't updated now
     // on tab parent.

But at least the same class events, say keypresses, are delivered in the order of generation, correct?
I am not sure what it means "async". Events may not be propagated to two targets tab and its parent togethr and so the code that process a tab cannot expect the event to have reached the tab parent?
compsitionChangeEvent has been received by the tab(?) and is being processed and the compositionTargetRange needs to be updated and so why can't we use the compoistionChangeEvent.TargetClauseLength() which we have received.

I will leave the rest to people in the know since, come to think of it, I am not even sure of the object hierarchy of
textarea used for inputting text for Google search web screen.

TIA

Based on comment 11 and comment 12, I am removing the regressionwindow-wanted tag.

Masayuki, more thoughts after the above detailed info from Ishikawa? Can this be fixed in 67?

Well, although I've not created the environment and I don't have much time to do that for now, looks like that I can fix it quickly. Wait a couple of hours...

(In reply to Masayuki Nakano [:masayuki] (JST, +0900) from comment #32)

Well, although I've not created the environment and I don't have much time to do that for now, looks like that I can fix it quickly. Wait a couple of hours...

Hi, if you post a patch candidate here (or somewhere), I can apply it to my local TB source tree mozilla/ and its subdirectory ./comm so that if the modification works on my local linux PC.

Anyway, thank you for the attention.

Here are test builds:
x64: https://queue.taskcluster.net/v1/task/Q3Yb5kohQJGSuRd2-KKTOQ/runs/0/artifacts/public/build/target.tar.bz2
x86: https://queue.taskcluster.net/v1/task/IqpL53n7S86x_5eepYxf1Q/runs/0/artifacts/public/build/target.tar.bz2

and here is the patch:
https://hg.mozilla.org/try/rev/52c138b5daa21bb33af272aa27675d83bda5e682

Could you check one of them?

(In reply to Masayuki Nakano [:masayuki] (JST, +0900) from comment #34)

Here are test builds:
x64: https://queue.taskcluster.net/v1/task/Q3Yb5kohQJGSuRd2-KKTOQ/runs/0/artifacts/public/build/target.tar.bz2
x86: https://queue.taskcluster.net/v1/task/IqpL53n7S86x_5eepYxf1Q/runs/0/artifacts/public/build/target.tar.bz2

and here is the patch:
https://hg.mozilla.org/try/rev/52c138b5daa21bb33af272aa27675d83bda5e682

Could you check one of them?

I checked the 64-bit version and it WORKS!

Thank you for the quick fix!

I am uploading the log for simple caee of converting touyoudaigaku と　とうようだいがく　into 東洋大学.

Hitting more convesion keys (spaces) will allow me to select still more alternative candidate strings.

I also tested the cursor movement (<- ->) to select different portions of the original string being converted into kanji candidate strings.
(Tested with famous watashinonamaewhanakanodesu -> わたしのなまえはなかのです　－＞　私の名前は中野です　example, too. Back when Wnn came out, it boasted that this conversion could be done without human intervention.)
This also worked.

So my take on this is the problem is fixed now.

Thank you !!!

Thank you, Ishikawa-san. Especially your log files helped me very much!

We've ignored clauses whose visual styles are not specified.
However, kinput2 with XIM protocol does not specify any styles
to non-selected clauses. Therefore, we fail to dispatch
eCompositionChange events if there is 2 or more clauses.

Note that the log in the bug indicates that we may set
selected clause type toTextRangeType::eConvertedClause and
last clause type to TextRangeType::eSelectedClause because
caret is always put at end of composition string. However,
this should not problem for now because nobody except plugins
on Windows refer this information.

(In reply to Masayuki Nakano [:masayuki] (JST, +0900) from comment #36)

Thank you, Ishikawa-san. Especially your log files helped me very much!

You are very welcome and I would like to thank Karl for suggesting me to obtain the event log (!).

BTW, in the patch,

// If the IME doesn't define clause at end of the composition,

you might want to mention wnn4+kinput2 combination as an example a la

// If the IME does not define clause at the end of the composition as in
// the case of the combination of Wnn4 jserver and kinput2-wnn4,

IMHO if my understanding of the nature of the bug is correct.
But you already explained it in the previous comment. So it is your call.

PS: I believe the Chinese people who have used XIM-based input before will be saved, too: I am afraid, though, that this problem might have put them off from using XIM-based input in the intervening years.
(I was curious why there were no complaints from Chinese or Korean users of XIM-based input frontend.)

The symptom was so difficult to describe.

Maybe I should have simply posted a bugzilla stating that "Japanese input does not work any more" when I first noticed the problem. Of course, then, someone would ask "how it is broken." and I needed to see what is broken exactly and how to explain this in an understandable manner. It took a me a couple of weeks to figure out what is not quite right and by then I switched to create Japanese text in Emacs and then copy and paste it into TB text area (!)

Hmm...

(In reply to ISHIKAWA, Chiaki from comment #38)

// If the IME doesn't define clause at end of the composition,

you might want to mention wnn4+kinput2 combination as an example a la

Ah, no. It's just last resort if IME does create clauses to cover all composition string. Actual fix for your environment is removing the block in SetTextRange().

PS: I believe the Chinese people who have used XIM-based input before will be saved, too: I am afraid, though, that this problem might have put them off from using XIM-based input in the intervening years.
(I was curious why there were no complaints from Chinese or Korean users of XIM-based input frontend.)

In these days, most distributions use ibus as default IM, and also some others use fcitx instead.

According to the telemetry in Beta 66, 69% users use ibus, 18% users use Fcitx, but XIM users is just 0.02%.

The symptom was so difficult to describe.

Maybe I should have simply posted a bugzilla stating that "Japanese input does not work any more" when I first noticed the problem. Of course, then, someone would ask "how it is broken."

Yeah, it's difficult to report any bugs which you don't aware of the area. So, just reporting it is a good start point, and if we cannot create such environment (e.g., bugs with proprietary IME, we can add logging code for collecting the behavior).

According to the telemetry in Beta 66, 69% users use ibus, 18% users use Fcitx, but XIM users is just 0.02%.

Ah, "XIM" meaning here is, IMContext claims it's created for "xim", but XMODIFIERS does not include IME name after "@im=". So, in your environment, it's collected as "kinput2" user.

　According to the telemetry in Beta 66, 69% users use ibus, 18% users use Fcitx, but XIM users is just 0.02%.

Aha, that is small!

Ah, "XIM" meaning here is, IMContext claims it's created for "xim", but XMODIFIERS does not include IME name after "@im=". So, in your environment, it's collected as "kinput2" user.

Exactly. This is how the environment variable is set.
XMODIFIERS=@im=kinput2

Is the collected data available somewhere?
I thought Fcitx suffered from a same X11 bug as did XIM a few years ago. But maybe Fcitx being a newer one produces style info.

Again, thank you very much for the fix. I will look forward to using the fixed version soon.

(In reply to ISHIKAWA, Chiaki from comment #41)

Is the collected data available somewhere?

Yeah, here is.

I thought Fcitx suffered from a same X11 bug as did XIM a few years ago. But maybe Fcitx being a newer one produces style info.

As far as I've tested, Fcitx sets underline, foreground color or background color for each clause. If so, we never meet this kind of bugs. I guess that this is caused by wnn because of not setting no style of non-selected clause.

https://hg.mozilla.org/mozilla-central/rev/075d0e6434cc