Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 84859 - (Regression) Mozilla lost 'over-the-spot'
Summary: (Regression) Mozilla lost 'over-the-spot'
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: kinput2
Version: 9
Hardware: All
OS: Linux
high
medium
Target Milestone: ---
Assignee: Akira TAGOH
QA Contact: Bill Huang
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2003-02-22 07:10 UTC by Warren Togami
Modified: 2013-01-10 21:39 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2004-10-21 10:30:52 UTC
Embargoed:


Attachments (Terms of Use)

Description Warren Togami 2003-02-22 07:10:48 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030215

Description of problem:
Bug #62307 has returned where Mozilla no longer has "over-the-spot" input by
default.  "over-the-spot" mode is crucial for Asian language character input.

Looking at mozilla-1.2.1-21.src.rpm there appears to be no signs of the xim
patch that went in mozilla-1.0.1.  Adding the following line to my prefs.js
manually has the expected behavior of activating "over-the-spot":

user_pref("xim.input_style", "over-the-spot");

Please read Bug #62307 for more information.  Please also vote for the upstream bug:
http://bugzilla.mozilla.org/show_bug.cgi?id=143540

Version-Release number of selected component (if applicable):
mozilla-1.2.1-21

Comment 1 Matt Wilson 2003-02-22 21:57:36 UTC
I think that on-the-spot xim is much better supported in Mozilla than
over-the-spot.  The pre-edit strings are rendered by Mozilla, making
the output match.  The downside is that the status window (for
kinput2, at least) pops down to the very bottom of the window, making
it somewhat harder to see what's going on.  Things get more strange
when you're doing link auto-search (new Mozilla feature).  If you use
on-the-spot you get to type in the status bar.  If you use
over-the-spot you end up typing in mid-air.
                                                                                
I am not a native Japanese speaker.  Heck, I only know that
"shift+space, 'nihongo', space" gives me something that I can read in
Japanese.  But at least for Japanese I think people are becoming
accustomed to the way that on-the-spot works.

If something needs correction, it's kinput2's candidate selection
window, which is just to far away from where you're typing.  This is
not the fault of using on-the-spot.
                                                                                
FWIW, from what I've seen in WinXP's IME, it's also on-the-spot now.
The candidate selection window is a fair amount better, though.


Comment 2 Warren Togami 2003-03-03 09:25:04 UTC
If a solution cannot be found in time, can we revert back to RH8.0's behavior
"over-the-spot" for release?  Otherwise this partially cripples Asian language
usability of this application.

Comment 3 Warren Togami 2003-04-06 05:14:53 UTC
Tested this on RHL9.  It appears to be over-the-spot now?

Close bug?


Comment 4 Warren Togami 2003-04-24 07:54:30 UTC
Sorry, I was wrong, it is not over-the-spot by default.  This is a regression
from RH8.


Comment 5 Warren Togami 2003-09-12 09:01:55 UTC
tagoh, I must be misunderstanding something crucial here, because over-the-spot
seems completely inoperative in mozilla-1.4, and I have never managed to get
on-the-spot to work in any Linux applications.

Due to this bug and Bug 84860, it is guaranteed that users will trigger Bug
104296 when they drag the Candidate Selection window since it is unreadable in
its default location.

Comment 6 Warren Togami 2004-10-21 10:30:52 UTC
IIIMF (the next generation beyond XIM and kinput2) does not do this
either, and it is acceptable, so I suppose this can be closed now.


Note You need to log in before you can comment on or make changes to this bug.