uim-skk's numeric conversion does not work properly with firefox
Categories
(Core :: Widget: Gtk, defect, P3)
Tracking
()
People
(Reporter: tosh2019, Unassigned)
Details
Attachments
(1 file)
21.55 KB,
image/jpeg
|
Details |
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:94.0) Gecko/20100101 Firefox/94.0
Steps to reproduce:
I'm on MX Linux 21 (Xfce) based on Debian 11 and I have installed Firefox 94.0.1 (64-bit) from the MX repo and also the Debian official package of uim-skk 1:1.8.8-9 from the Debian stable repo.
uim-skk has a unique feature which enables you to input different representations of numbers used in Japanese but it does not work properly in Firefox windows when candidates include ASCII numbers, i.e. single width numbers.
In Japanese writing, we use double width numbers and kanji characters representing numbers as well as single width numbers and numeric conversion enables you to choose between these different representations of the same number.
Now, for example, in order to have "5人" with a single width number type Ctrl-j (activate skk) Q (enter conversion mode) 5 (number) n i n n (Roma-Ji) and then type Space (start conversion).
Actual results:
I suppose you have a blank, a candidate with a double width number ("5人") and one with a kanji number ("五人") in some order or other as you type Space a couple of times if necessary. But you never have a candidate with a single width number ("5人").
Expected results:
You should have a candidate with a single width number ("5人") as well.
As you can see in the attached image, the candidate A is blank in a Firefox window while the same candidate A with a single width number shows in a gedit window.
And even when I select the blank candidate A, nothing is inserted.
Comment 1•3 years ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::Widget: Gtk' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.
I'm using uim-skk modified to handle utf-8, so this bug appears a little differently. It is not that the corresponding candidate does not appear, but that an extra string is appended after the corresponding candidate. It's mostly " (U+FFFD)" , but readable characters also appear, like the following
5人(U+FFFD)(U+FFFD)(U+FFFD)5に
5人(U+FFFD)(U+FFFD)(U+FFFD)(U+FFFD)#0人
5人(U+FFFD)(U+FFFD)(U+FFFD)(U+FFFD)(U+FFFD)insert
5人((U+FFFD)(U+FFFD)U+FFFD)五
5人(U+FFFD)(U+FFFD)(U+FFFD)(U+FFFD)root
5人(U+FFFD)(U+FFFD)A
Here, "#0人" and "五" are information that uim is supposed to handle internally, and it is unnatural that this information is being sent to firefox. So I suspect that the problem is on the uim side.
However, in my case, there may be a problem with my modification to handle utf-8, so please keep this information for reference.
Additional information:
In my case, this bug occurs only when the number to be entered is a single digit, not when the number is two or more digits.
In the uim-skk-utf8 case, the issue has been resolved via
https://github.com/uim/uim/pull/186 .
Updated•3 years ago
|
Description
•