In WhatsApp and Telegram (used in Firefox) in the middle of the message, when a new word is being started, the first character disappears

[mike-fabian]

          While the initial `É` problem is fixed, Mike, from time to time, again on Firefox Web WhatsApp, in the middle of the message, when a new word is being started, the first character disappears. 

That occurs with not accented first characters, and I have not, until now, devised a systematic way of reproducing the issue.

The issue does not occur when using Chrome.

Originally posted by @psads-git in #471 (comment)

[mike-fabian]

Happens even more often on Telegram.

[mike-fabian]

Video using WhatsApp:
#471 (comment)

[psads-git]

It appears that some randomness commands the occurrence of the issue, Mike: Sometimes, it occurs very often while writing a same message.

[mike-fabian]

I think I have a fix/workaround.

My current fix/workaround is already an improvement, the first character of a new word now never seems to vanish in WhatsApp and Telegram when using in Firefox.

But, when the input becomes empty after a commit and a prediction should appear because the option

Minimum numbers of chars for completion  [   0]

is used (The problem reported here seems to occur only when that option is used), then sometimes that prediction does not appear.

That is already much better then when first characters of new words disappear, with my current fix/workaround, one sometimes does not get a prediction when there should be one, that is not nice but not as bad as a typed character disappearing.

[mike-fabian]

Video showing the remaining problem in Telegram. About every second time, the prediction which should appear when the input is empty does not appear. It is not exactly every second time, just on the average about every second time:

Peek.2023-12-12.17-54.mp4

[psads-git]

Yes, I agree with you that the workaround, although not the best solution, is much better than the current status quo.

Maybe, another workaround is to pass that option from 0 to 1.

[psads-git]

Yet, another workaround is to use Chrome instead of Firefox! ;-)

[mike-fabian]

Yes, I agree with you that the workaround, although not the best solution, is much better than the current status quo.

Maybe, another workaround is to pass that option from 0 to 1.

But we want to be able to continue to use 0 for that option.

[mike-fabian]

Now I have improved my workaround to also show the predictions on empty input always when they should be shown.
Test builds for ibus-typing-booster-2.24.6 are here:

https://copr.fedorainfracloud.org/coprs/mfabian/ibus-typing-booster/builds/

[mike-fabian]

Seems to work with ibus-typing-booster-2.24.6:

Peek.2023-12-12.21-33.mp4

[psads-git]

Thanks, Mike. It appears that it is working properly, but, maybe, we should wait for longer to make sure the issues does not reappear.

[psads-git]

There is an innocuous side-effect: The suggested word is repeated in gedit, Mike. That does not affect the usability of ibus-typing-booster at all.

Please, see the attached video.

Peek.2023-12-13.11-38.mp4

[mike-fabian]

You mean this temporary duplication of the word uma here?:

[psads-git]

Yes, Mike. That is innocuous though.

[mike-fabian]

Before the fix/workaround for this issue here I did the following when the word uma was in preedit and a space was typed:

• commit the word uma
• update the preedit to empty
• record what was typed into the user database
• try to predict the next word
• update to preedit to:
  • empty if no next word could be predicted
  • the next word if one could be predicted (often in colour, red in your case)

But in this procedure, the preedit is update twice during the same key event. That causes sometimes disappearing characters in WhatsApp and Telegram. If the preedit is updated twice in quick succession, WhatsApp and Telegram trigger a callback to do_reset() which may cause characters to be lost.

Now I do only this:

• commit the word uma
• record what was typed into the user database
• try to predict the next word
• update to preedit to:
  • empty if no next word could be predicted
  • the next word if one could be predicted (often in colour, red in your case)

I.e. I omitted the first update of the preedit to empty directly after the commit. So now the word uma is committed, but the preedit still contains the word uma (shown underlined!) and the commit causes the preedit to move to the right of the committed word. So now you see umauma where the second, underline uma is the preedit. Now the other stuff is done

• record what was typed into the user database
• try to predict the next word

That takes some time and during that time the underlined preedit containing uma stays visible. Then, when that work is done, the preedit is updated:

• update to preedit to:
  • empty if no next word could be predicted
  • the next word if one could be predicted (often in colour, red in your case)

And the old preedit containing uma vanishes.

Before I had an update to an empty preedit immediately after the commit, in the next line in the source code where the commit really happend. Therefore,
the preedit was shown as empty (i.e. invisible) while doing the extra stuff after the commit:

• commit

• update predit to empty (make it invisible)

• Now do some work while the preedit is invisible

• update the preedit again depending on the results of the work done after the commit

But now it is

• commit

• Now do some work while the old preedit is still visible

• update the preedit only a single time at the end when all work is done.

So with the new code, it takes too much time until everything is done and the preedit is updated to the final result at last. I cannot make that work inbetween faster, so I wonder what I could do here.

Doing fewer updates of the preedit seems generally like a good idea. Not only because of WhatsApp and Telegram in Firefox, similar problems sometimes occur when using Gnome Wayland because of problems in Mutter. When doing ibus actions like

• commit
• update predit
• forward or return a key event

then Mutter sometimes changes the order of the events or looses some of the events. I.e. when committing text and then forwarding a space, the order might be reversed in Mutter and the result may be text instead of the desired text . Committing text and then committing instead of forwarding the space key does not work either because Mutter then ignores the first commit completely and one just gets . First appending the space to text and then committing text in one single action makes it work.

Overall I got the impression that it is good to do as few of these ibus actions as possible during the processing of one key event.

• Instead of doing multiple commits, try assembling all the text into one string first and commit that one in a single action.
• Instead of doing a commit and then forwarding a key event, try to append the key event to the commit (That works fine for space because a space is just text and can be added easily to the text to be comitted and then committed together. It does not work for all keys, one cannot add something like Control+space to a string, it also does not work well for Return, but at least for the keys where this works, it is good to avoid the forwarding and to only a commit
• Instead of doing multiple updates of the preedit while work is in progress, wait until all is done and update the preedit only in the end. The disadvantage is of course that while the work is still in progress, an incorrect preedit may still be shown.

I don’t like that old preedit lingering around so long.

But I have no idea what I can do here. Updating the preedit again directly after the commit brings back the problem in WhatsApp and Telegram and maybe also causes problems in Mutter (Gnome Wayland) and maybe in other places as well.

Doing many ibus actions during processing one key event should work, but what can I do when there are applications where it doesn't work?

Doing as few such ibus actions as possible during one key event reduces the likelyhood that something can go wrong. If there is only one action, it cannot be overwritten by another action or change order with another action.

So fewer actions makes it more reliable, but fewer update preedits may cause a wrong preedit linger for longer causing this very irritating flicker.

[psads-git]

That is really an intricate problem, Mike! Personally, I do not mind the duplicated umauma.

[mike-fabian]

Even with Minimum chars for completion [ 1] the old preedit is sometimes visible for a short moment after committing with space. Although in that case it is extremely short, the only work which is done in that case after the commit is the recording to the user database which is very fast. So it is not very obvious and sometimes even fast enough to be invisible.

But predicting the next word when using Minimum chars for completion [ 0] is more work and takes long enough that the lingering of the old preedit is often quite clearly visible.

[mike-fabian]

That is really an intricate problem, Mike! Personally, I do not mind the duplicated umauma.

Yes, I think if I only have the choice between loosing characters or reversing order in some applications and some visual distraction by a preedit which stays too long, I choose the visual distraction.

Better some visual distraction which does not harm other than hurt the eyes than a clearly wrong result.

If I could make the prediction of the next word faster, this would become less visible. But looking at the code to predict the next word, I see no obvious way to make it faster.

[mike-fabian]

Fix included in https://github.com/mike-fabian/ibus-typing-booster/releases/tag/2.24.10in