Incorrect handling of '0' when displaying a list of candidates

[bochecha]

Let's say the user types hi in Quick (or h*i in Cangjie). We're giving them a list of candidates.

They can then press a number between 1 and 9 to select a candidate on the currently displayed page.

But what if they type 0?

Here's what happens:

Traceback (most recent call last):
  File "/usr/lib/python3.4/site-packages/ibus_cangjie/engine.py", line 333, in do_process_key_event
    return self.do_number(keyval)
  File "/usr/lib/python3.4/site-packages/ibus_cangjie/engine.py", line 235, in do_number
    return self.do_select_candidate(int(IBus.keyval_to_unicode(keyval)))
  File "/usr/lib/python3.4/site-packages/ibus_cangjie/engine.py", line 291, in do_select_candidate
    selected = self.lookuptable.get_candidate(page_index+index-1)
OverflowError: -1 not in range 0 to 4294967295

That triggered the ABRT crash catcher in Fedora, and a user was nice enough to report the issue.

[chanueting]

Thanks for posting right here.
However, I have tried to type h*i in Cangjie and choose 0 again without the same issue.
What I have noticed is:
h*i + 0 => 0 is input, the drop down is still in effect, without crash.
h*i + space + 0 => 待 is input, the drop down is gone, without crash.
Sorry I cannot reproduce it again. However, if you have any idea / test case. Do feel free to let me work on it.

Oops, I reproduce it after restarting the ibus, it crashed and abrt caught it.
Sounds like the symptom above happens after the first crash.

[bochecha]

h*i + 0 => 0 is input, the drop down is still in effect, without crash.

You don't see the crash, probbaly because ABRT caught it, and since you've already reported it, then it just ignores it.

But I assure you it's there, here's how to reproduce it:

1. switch to a non-cangjie input method (for example, plain English)
2. kill all the ibus-cangjie related processes
3. run ibus-cangjie manually in the terminal: /usr/lib/ibus-cangjie/ibus-engine-cangjie --ibus cangjie
4. switch to another window where you can input text
5. switch to Cangjie
6. h*i0
7. get back to the terminal, and you'll see the traceback I pasted above

Really, all that's happening is that ABRT doesn't show you a popup window about the crash, because you've already reported it to the Fedora bug tracker (and thank you very much for that!)

[chanueting]

Thanks for pointing out the ABRT behaviour. It keeps printing traceback in the terminal on every crash (at the time typing 0).
I have tried using MS Windows Quick and it would keep inserting 0 while waiting for valid input (number between 1 and 9). Do you think it is possible in ibus? Thanks.

[bochecha]

What you describe is the intended behaviour. It's what we wanted to implement.

The fact that it isn't what happens is why I opened this bug report. 😉

We just need to actually fix it.