Bug 1690326

Summary: Input with ibus-bogo-0.4-19.fc30 repeatedly deletes text chars before the cursor
Product: [Fedora] Fedora Reporter: sandeep shedmake <sshedmak>
Component: ibus-bogoAssignee: Truong Anh Tuan <tuanta>
Status: CLOSED EOL QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: high    
Version: 35CC: i18n-bugs, mfabian, psatpute, sshedmak, tfujiwar, tuanta
Target Milestone: ---Keywords: i18n
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2022-12-13 15:12:51 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
screencast showing broken Vietnamese input with ibus-bogo-0.4-19.fc30 none

Description sandeep shedmake 2019-03-19 09:54:40 UTC
Created attachment 1545550 [details]
screencast showing broken Vietnamese input with ibus-bogo-0.4-19.fc30

Description of problem:
Input of Vietnamese string using Vietnamese (BoGo) input method deletes all / any character to the left of the cursor


Version-Release number of selected component (if applicable):
ibus-bogo-0.4-19.fc30.noarch


How reproducible:
Always


Steps to Reproduce:
1. Do Fedora-30 installation (Workstation-Live iso) in preferred LANG (say: Marathi / mr)
2. Do successful gdm login
3. Follow https://fedoraproject.org/wiki/QA:Bogo  i.e. install ibus-bogo & enable vietnamese (BoGo) input method from the gnome-shell panel and type "Khoong ..."


Actual results:
Deletes all / any character to the left of the cursor, until other input method is switched


Expected results:
Vietnamese string "Không có gì quí hơn độc lập tự do".

Additional info:
Screen-cast attached

Comment 1 fujiwara 2019-03-20 03:26:11 UTC
ibus-bogo has a problem in Wayland to send the wrong keycodes.
I'd suggest to use preedit instead of forwarding key events or ibus-unikey instead.

Comment 2 sandeep shedmake 2019-09-10 23:11:04 UTC
(In reply to fujiwara from comment #1)
> ibus-bogo has a problem in Wayland to send the wrong keycodes.
> I'd suggest to use preedit instead of forwarding key events or ibus-unikey
> instead.

Reported problem persists with f31 (ibus-bogo-0.4-20.fc31).

Yep, 'ibus-unikey' works as an alternative Vietnamese IME for ibus.

Comment 3 Truong Anh Tuan 2019-09-11 02:41:06 UTC
I am still using both fine on my F30 Workstation.
Let me check this more details later.

Comment 4 Mike FABIAN 2019-09-11 12:10:05 UTC
What is the difference between ibus-bogo, ibus-unikey, and the Vietnamese input
methods available in m17n-db (which are also available in ibus-typing-booster)?

$ ls /usr/share/m17n/vi-*.mim
/usr/share/m17n/vi-base.mim     /usr/share/m17n/vi-nom.mim    /usr/share/m17n/vi-viqr.mim
/usr/share/m17n/vi-han.mim      /usr/share/m17n/vi-tcvn.mim   /usr/share/m17n/vi-vni.mim
/usr/share/m17n/vi-nom-vni.mim  /usr/share/m17n/vi-telex.mim

If they are all different, then maybe it would be useful to add vi-bogo.mim and vi-unikey.mim which
mimic  the behaviour of ibus-bogo and ibus-unikey to be able to use these Vietnamese input methods
with ibus-typing-booster (to get word completions).

Comment 5 Mike FABIAN 2019-09-11 14:49:01 UTC
(In reply to Truong Anh Tuan from comment #3)
> I am still using both fine on my F30 Workstation.
> Let me check this more details later.

It works on  Xorg, so maybe it works for you because you use Gnome on Xorg, not on Wayland.

Comment 6 Truong Anh Tuan 2019-09-12 01:50:47 UTC
(In reply to Mike FABIAN from comment #5)
> (In reply to Truong Anh Tuan from comment #3)
> > I am still using both fine on my F30 Workstation.
> > Let me check this more details later.
> 
> It works on  Xorg, so maybe it works for you because you use Gnome on Xorg,
> not on Wayland.

I am currently using Wayland. Just checked:

[tuanta@tuanta ~]$ loginctl show-session 2 -p Type
Type=wayland

Comment 7 Truong Anh Tuan 2019-09-12 02:00:07 UTC
(In reply to Mike FABIAN from comment #4)
> What is the difference between ibus-bogo, ibus-unikey, and the Vietnamese
> input methods available in m17n-db (which are also available in
> ibus-typing-booster)?

Actually, I am not familiar with this. I am just a packager, not a software developer.

> $ ls /usr/share/m17n/vi-*.mim
> /usr/share/m17n/vi-base.mim     /usr/share/m17n/vi-nom.mim   
> /usr/share/m17n/vi-viqr.mim
> /usr/share/m17n/vi-han.mim      /usr/share/m17n/vi-tcvn.mim  
> /usr/share/m17n/vi-vni.mim
> /usr/share/m17n/vi-nom-vni.mim  /usr/share/m17n/vi-telex.mim

But I think these are Vietnamese keyboards, the way to type Vietnamese (I am using "vi-telex").

ibus-bogo and ibus-unikey are a bit different as they are software for Vietnamese language processing with additional features:
+ Spelling checks.
+ Text processing.
+ Different Vietnamese charsets.
...

Comment 8 Mike FABIAN 2019-09-12 08:31:22 UTC
(In reply to Truong Anh Tuan from comment #7)
> (In reply to Mike FABIAN from comment #4)
> > What is the difference between ibus-bogo, ibus-unikey, and the Vietnamese
> > input methods available in m17n-db (which are also available in
> > ibus-typing-booster)?
> 
> Actually, I am not familiar with this. I am just a packager, not a software
> developer.
> 
> > $ ls /usr/share/m17n/vi-*.mim
> > /usr/share/m17n/vi-base.mim     /usr/share/m17n/vi-nom.mim   
> > /usr/share/m17n/vi-viqr.mim
> > /usr/share/m17n/vi-han.mim      /usr/share/m17n/vi-tcvn.mim  
> > /usr/share/m17n/vi-vni.mim
> > /usr/share/m17n/vi-nom-vni.mim  /usr/share/m17n/vi-telex.mim
> 
> But I think these are Vietnamese keyboards, the way to type Vietnamese (I am
> using "vi-telex").

How are you using vi-telex? If I understand correctly, you are not using /usr/share/m17n/vi-telex.mim
because you are using neither ibus-m17n nor ibus-typing-booster. So the "vi-telex" you are using
must be some Vietnamese keyboard layout from xkb, I guess. But I can find  no “telex” in
/usr/share/X11/xkb/symbols/vn so I am wondering what exactly you are using.

> ibus-bogo and ibus-unikey are a bit different as they are software for
> Vietnamese language processing with additional features:
> + Spelling checks.
> + Text processing.
> + Different Vietnamese charsets.
> ...

Is there a specification what exactly ibus-bogo and ibus-unikey are supposed to do?

The Fedora test case for  ibus-bogo, https://fedoraproject.org/wiki/QA:Bogo, has:

     type "Khoong cos gif quis hown ddoocj laapj tuwj do".
     ...
     you will get: "Không có gì quí hơn độc lập tự do".

That looks like a transliteration which could be done easily with a m17n input method as well.
But for creating a m17n input method it would be nice to have some specification, that would be easier  than just reverse engineering ibus-bogo.

Comment 9 Truong Anh Tuan 2019-09-13 07:59:37 UTC
(In reply to Mike FABIAN from comment #8)
> 
> How are you using vi-telex? If I understand correctly, you are not using
> /usr/share/m17n/vi-telex.mim
> because you are using neither ibus-m17n nor ibus-typing-booster. So the
> "vi-telex" you are using
> must be some Vietnamese keyboard layout from xkb, I guess. But I can find 
> no “telex” in
> /usr/share/X11/xkb/symbols/vn so I am wondering what exactly you are using.

Sorry for getting you confused.
I meant I use "Telex" method to type Vietnamese.

> > ibus-bogo and ibus-unikey are a bit different as they are software for
> > Vietnamese language processing with additional features:
> > + Spelling checks.
> > + Text processing.
> > + Different Vietnamese charsets.
> > ...
> 
> Is there a specification what exactly ibus-bogo and ibus-unikey are supposed
> to do?
> 
> The Fedora test case for  ibus-bogo, https://fedoraproject.org/wiki/QA:Bogo,
> has:
> 
>      type "Khoong cos gif quis hown ddoocj laapj tuwj do".
>      ...
>      you will get: "Không có gì quí hơn độc lập tự do".

This is the main/core function so this test is mandatory.

> That looks like a transliteration which could be done easily with a m17n
> input method as well.
> But for creating a m17n input method it would be nice to have some
> specification, that would be easier  than just reverse engineering ibus-bogo.

Not sure. I will give a try.

Comment 10 Mike FABIAN 2019-09-13 09:26:09 UTC
(In reply to Truong Anh Tuan from comment #9)
> (In reply to Mike FABIAN from comment #8)
> > 
> > How are you using vi-telex? If I understand correctly, you are not using
> > /usr/share/m17n/vi-telex.mim
> > because you are using neither ibus-m17n nor ibus-typing-booster. So the
> > "vi-telex" you are using
> > must be some Vietnamese keyboard layout from xkb, I guess. But I can find 
> > no “telex” in
> > /usr/share/X11/xkb/symbols/vn so I am wondering what exactly you are using.
> 
> Sorry for getting you confused.
> I meant I use "Telex" method to type Vietnamese.

I am still confused, are you using ibus-bogo, or are you using vi-telex.mim through
ibus-m17n or ibus-typing-booster?

Comment 11 Truong Anh Tuan 2019-09-13 09:29:24 UTC
(In reply to Mike FABIAN from comment #10)
> I am still confused, are you using ibus-bogo, or are you using vi-telex.mim
> through ibus-m17n or ibus-typing-booster?

I am currently using ibus-bogo and ibus-unikey, not ibus-m17n or ibus-typing-booster.

Comment 12 Mike FABIAN 2019-09-13 09:32:24 UTC
(In reply to Truong Anh Tuan from comment #9)

> > The Fedora test case for  ibus-bogo, https://fedoraproject.org/wiki/QA:Bogo,
> > has:
> > 
> >      type "Khoong cos gif quis hown ddoocj laapj tuwj do".
> >      ...
> >      you will get: "Không có gì quí hơn độc lập tự do".
> 
> This is the main/core function so this test is mandatory.
> 
> > That looks like a transliteration which could be done easily with a m17n
> > input method as well.

And this test works already when using the vi-telex.mim input method
via ibus-typing-booster.

And it also works when using vi-telex.mim via ibus-m17n.

So I wonder what additional benefit ibus-bogo really offers. Should
we bother fixing ibus-bogo at all?

Comment 13 Mike FABIAN 2019-09-13 15:55:04 UTC
(In reply to Mike FABIAN from comment #12)

> So I wonder what additional benefit ibus-bogo really offers. Should
> we bother fixing ibus-bogo at all?

I had a look at the ibus-bogo source code and I think I can fix it with some effort...

Comment 14 Mike FABIAN 2020-04-07 15:41:57 UTC
Unchanged in F32.

Comment 15 sandeep shedmake 2020-09-08 09:54:59 UTC
Reproduced in F33.

Comment 16 Pravin Satpute 2020-09-08 10:17:42 UTC
Thanks Mike for volunteering to fix this issue. I think, good to assign issue to yourself. 

Truong Anh Tuan already mentioned, he is only doing packaging at the moment.

Comment 17 Ben Cotton 2021-11-04 17:32:12 UTC
This message is a reminder that Fedora 33 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 33 on 2021-11-30.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
Fedora 'version' of '33'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 33 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 18 fujiwara 2021-11-10 09:13:12 UTC
Under the discussion in GNOME-Shell upstream.

Comment 19 Ben Cotton 2022-11-29 16:46:07 UTC
This message is a reminder that Fedora Linux 35 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora Linux 35 on 2022-12-13.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
'version' of '35'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, change the 'version' 
to a later Fedora Linux version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora Linux 35 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora Linux, you are encouraged to change the 'version' to a later version
prior to this bug being closed.

Comment 20 Jens Petersen 2022-12-13 03:12:42 UTC
Mostly seems okay in F37 anyway

Comment 21 Ben Cotton 2022-12-13 15:12:51 UTC
Fedora Linux 35 entered end-of-life (EOL) status on 2022-12-13.

Fedora Linux 35 is no longer maintained, which means that it
will not receive any further security or bug fix updates. As a result we
are closing this bug.

If you can reproduce this bug against a currently maintained version of Fedora Linux
please feel free to reopen this bug against that version. Note that the version
field may be hidden. Click the "Show advanced fields" button if you do not see
the version field.

If you are unable to reopen this bug, please file a new report against an
active release.

Thank you for reporting this bug and we are sorry it could not be fixed.