Closed Bug 176514 Opened 22 years ago Closed 21 years ago

[gtk2] text input problems

Categories

(Core :: XUL, defect)

Product:
Core
Component:
XUL
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: blizzard, Assigned: blizzard)

References

Details

Attachments

(1 file, 10 obsolete files)

final patch?
22.78 KB, patch
Details | Diff | Splinter Review 
I'm seeing an odd problem with using the spacebar triggering typeaheadfind when
it shouldn't.

Steps to reproduce:

1. Load a web page.
2. Click with the mouse to focus in the browser area
3. Hit the space bar

Expected results:

Web page should scroll down.

Actual results:

typeaheadfind starts to look for links that contain spaces.

I've discovered that if I hack nsWindow::IMEGetContext() to always return NULL,
effectively disabling IME, that I don't have this problem so that code is
suspect.  I'll investigate more.
Blocks: gtk2
I'm seeing this problem with the 2002102322 gtk2 snapshot build. In addition,
often all keyboard shortcuts stop working, and I can't type in the location bar.
The only workaround I know of is to open a new window and close the one this
happens in.
I'll investigate it,too.
I've seen this problem with that bit of code disabled, so there's some other
race condition here.
Summary: [gtk2] text input problems related to IM code → [gtk2] text input problems (focus problems)
*** Bug 178068 has been marked as a duplicate of this bug. ***
For the moment I've disabled the XIM code since it was what was causing this
issue.  In addition I was also seeing unrelated focus problems which I'm pretty
sure that I've fixed seperately.

OK, here's what is going on here.  I hope that I do a good job of explaining this.

It turns out that one of the features of gtk2 is all text goes through, or can
go through, the IM code, assuming there's a context created.  In Mozilla's case,
since we create a context for all windows, we send all text through the IM code
instead of as key press and key release events.

I haven't investigated deeply but I'm guessing that the hot key problem that I'm
seeing (space in the HTML area not paging down, 'm' not marking messages as
unread in the mail window) are because they hot key code doesn't know how to
read the IME commit event as a hot key.

Alternatively, and I think that this is the correct way to do it, is to only
create IM contexts for native windows that actually have to compose text.  My
big concern is that since we are no longer sending key_press and key_release
events we're going to be breaking the DOM event model, and badly at that.

So, I'm not entirely sure where to go from here.

Who else can help us sort this out?
Summary: [gtk2] text input problems (focus problems) → [gtk2] text input problems
some IRC discussion:

<JayYan> I recalled that John's origin patch is ic-per-widget, katakai suggested
to change into ic-per-shell, for good performance, stability.
<blizzard> if I'm reading the code, ic-per-shell is what is in the code right now
<JayYan> yes
<robin> will it work if we change it back to ic-per-widget?
<blizzard> I don't think that's the problem
<JayYan> I saw your comments there.
<JayYan> now, every window is sharing one context. your suggestion is to creat
context for the window who really needs it, say, editable window. is that right?
<blizzard> right, as one possible solution
<JayYan> but for the editable window, such as editable textarea, it also has
shortcuts, such as redo, undo.. will its individual context still break the
usage of the shortcuts? 
<blizzard> I'm not 100% sure
<blizzard> that's one of the things that we need to figure out
<JayYan> ok
<JayYan> now the code of IM is disabled in trunk? instead of deleted?:)
<blizzard> that's correct
<blizzard> I just commented out the -DUSE_XIM in the makefile
take on it.
I'll try to sort this out.
blizzard, now this bug show the advantage of USE_XIM. :)

Blizzard,

I found it's more like a bug for gtk+-2.0 or the IM. Not only mozilla can not
work well but also the other native gnome applications. They just seems like
work but actually not. These gnome applications can only deal with the gtk-based
hotkey. 

For example, in a gnome-terminal under Chinese locale (my os is RedHat Linux
8.0), if you press alt-f, it's OK, the file menu is triggered. But if you press
alt-a which is not a hotkey of gnome-ternimal, an "a" is shown. If you type
alt-2 or alt-3 which may means something to my bash shell but not to the
gnome-terminal , only a '2' or '3' is shown. That's just like how moz+gtk2 loses
its hotkey. All above can be reproduced without the IM being triggered.
Help us, owen wan kenobi.

We're using a multicontext.  Would it help us to only use a specific kind of
context? (A _total_ stab in the dark.)
There seems to be some expectation of magic here, but it is really very
simple.

The code flow is always going to be one of:

 - The application checks for hotkeys
 - The application feeds unhandled keys to GtkIMContext

or:

 - THe application feeds keys to GtkIMContext
 - Anythign that GtkIMContext doesn't handle is checked for hotkeys.

GTK+ generally takes the first, approach, though there are
some problems with it (http://bugzilla.gnome.org/show_bug.cgi?id=90082)

Taking the second approach is also possible, but it requires the input
method not to eat the hotkeys. It's that simple.

[ And no, this has nothign to do with GtkIMMultiCOntext. Using it
  is correct ]



Mozilla's event model doesn't distinguish between "hotkeys" and typing; the
widget library gets key events, it feeds key events to the object that has the
focus, the object consumes the event or not, then passes it on to the next
object in the chain.

> Alternatively, and I think that this is the correct way to do it, is to only
> create IM contexts for native windows that actually have to compose text.  My
> big concern is that since we are no longer sending key_press and key_release
> events we're going to be breaking the DOM event model, and badly at that.

That might be the best solution, but it's still a bit scary.
If we go through gtk IM code, then we should be able to send the editor text
input events rather than key down/up/press events.  That shouldn't break any DOM
model; I think we already do mac IM that way (Joe, help?)  But we'd better still
send regular key events when a modifier (other than shift) is pressed, and if
we're trying to make this decision in the event handler, we have to worry about
what happens in text widgets (such as in chatzilla and AIM) where an unmodified
key (return, for example) is used for something other than input.  Maybe they've
already solved that problem for mac.

Assuming Akkana means mac IME when she says "mac IM", I can answer that I have no 
bloomin idea. By the time I see IME stuff in editor, it is already out of the 
event system.  Different os's handle IME differently, and i10n folks worte the 
platform dependent code.  Try Frank Tang or Roy Yokoyama.

Only create IM context for editable widget might not solve the problem. We still
suppose the hotkey working while the focus is in an editbox. For example, when
the focus is in the url bar and we press the alt-f, what we want is the
menu-File being triggered. But for current gtk+-2.0 ( either 2.0.8 or 2.1.2 as
far as I tried in Chinese Locale w/without trigering the Chinese IM, of RH8.0),
as long as the alt-f goes into the IM, only an 'f' comes out. The alt gets lost.

I checked the gtkimcontextxim.c and found that
gtk_im_context_xim_filter_keypress deal with the XLookupChars and XLookupBoth as
the same thing after looking up string. That means either an 'a' or an 'alt-a'
is typed in, although the status of looking up string are difference ( for 'a',
it is XLookupChars; for 'alt-a', it is XLookupBoth with a keysym), the 'commit'
method is callbacked only with the string while the information of 'alt' is lost
and the filter finally returns as true.

I was not quite sure if the hotkey could be considered as eaten by IM or the Gtk
wrapper for XIM. I did a rough test by just removing XLookupBoth from the clause
in gtk_im_context_xim_filter_keypress like:
   if (status == XLookupChars ) /*|| status == XLookupBoth)*/
Then the hotkeys of mozilla came back, even the spacebar, and IM also worked fine. 

I don't mean to modify the gtkincontextxim.c like that. But there does have some
problem with XLookupBoth at least for Chinese locale. Just open an gtk2
application such as gedit, gnome-terminal or whatever and type alt-something
except the application hotkey and see what you get.
Well, a widget is certainly free not to send alt-letter combinations
to the input method at all.

This is what the VTE widget (what will be used for gnome-terminal
in GNOME-2.2) does.

But if you do send these combinations, GTK+ basically has to trust
the input method as to whether the input method uses them for itself
or not.

I don't exactly understand when a input method would return XLookupBoth,
so I don't know if changing GtkIMContextXIM would make sense or not.

> Well, a widget is certainly free not to send alt-letter combinations
> to the input method at all.

It could be a solution. Only it's a little hard for the hotkey other than
alt-letter, for example, the spacebar. Actually, the problem might not due to
the input method.

> But if you do send these combinations, GTK+ basically has to trust
> the input method as to whether the input method uses them for itself
> or not.
I agree. But does it mean the input method uses them for itself when it returns
XLookupBoth instead of XLookupChars? And, if Gtk+ could not make sure what the
XLookupBoth might mean, is it better to keep the information to the applications
and let them to have a choice? If GTK+ misunderstands the input method, how
could I trust the GTK+? Just not to send the alt-letter through Gtk+ to the
input method sound me more like a workaround from an untrustable layer :P.
Attached patch a workaround patch for mozilla (obsolete) — — Splinter Review 
Avoid commit the string via TextEvent if the IME does not actually change the
keystroke value. That's a workaround because if gtkimcontextxim does this for
us, we don't need this patch. I have a patch for gtk+ at
http://bugzilla.gnome.org/show_bug.cgi?id=98447 .

seeking r=?
Attached patch patch (obsolete) — — Splinter Review 
patch with encoding tweaks according to Owen's advice. 
This is still a workaround patch.
Attachment #106620 - Attachment is obsolete: true
Attachment #106630 - Flags: review?(blizzard)
*** Bug 180536 has been marked as a duplicate of this bug. ***
Note that I don't think we'll be making any GTK+ fixes here ... see
my comments on http://bugzilla.gnome.org/show_bug.cgi?id=98447.

I don't think the "workaround" here is ridiculous; as I understand it,
the current logic is:

 A) Send the key press event to the input method
 B) If the input method converts the key press into a string
    then send a "IM commit text" event and do no further processing.
 B')If the input method filters the key without generating any
    string, then do no further processing.
 C) Otherwise check for hotkeys; if one is found activate it,
    do no further processing
 D) Otherwise, go through to the controls default key press handler,
    which may insert string from the event.

Almost all strings get eaten at B), so C), D) don't get hit.

The proposed changed logic seems to be:

 A) Send the key press event to the input method
 B) If the input method converts the key press into a string
    *that is not different from the string that Mozilla woudl
    convert the event into without an input method*, then send 
    a "IM commit text" event and do no further processing
 B')If the input method filters the key without generating any
    string, then do no further processing.
 C) Otherwise check for hotkeys; if one is found activate it,
    do no further processing
 D) Otherwise, go through to the controls default key press handler,
    which may insert string from the event.
 
In other words, there is an idea that we separate key events into:

 1) Those that immediately generate a single ::commit signal with
    the text identical to the text from
      gdk_keysym_to_unichar
 2) Those key events that are filtered by the IM context but do 
    not match 1).
 3) All other key events

Key events in class 1) are potential hot keys and need to go through
the normal mozilla key handling mechanism.

Blizzard: note that if you go with something like this, you must
  make sure that you aren't using GdkEventKey->string as the "string"
  for a key event; as we discussed earlier, this is an obsolete
  field.

Owen, 

I assume that you accept the idea of my proposal patch for mozilla, is that right?
*** Bug 167503 has been marked as a duplicate of this bug. ***
Attached patch a refined patch (obsolete) — — Splinter Review 
seeking r=?
Attachment #106630 - Attachment is obsolete: true
Blocks: 174058
Attachment #106630 - Flags: review?(blizzard)
Attachment #107417 - Flags: review?(blizzard)
*** Bug 186589 has been marked as a duplicate of this bug. ***
Attached patch patch (obsolete) — — Splinter Review 
a more arranged patch. also fixed a bug for on-the-spot preediting
introduced(not caused) by previous patch.
Attachment #107417 - Attachment is obsolete: true
Attachment #107417 - Flags: review?(blizzard)
Attachment #110562 - Flags: review?(blizzard)
*** Bug 193130 has been marked as a duplicate of this bug. ***
*** Bug 193509 has been marked as a duplicate of this bug. ***
Blocks: 187784
Latest patch doesn't fix text input problem in GtkEmbed (tried with galeon 1.3.2
+ patched GTK2 mozilla )
Attached patch Fixed patch for GTKMozEmbed (obsolete) — — Splinter Review 
the following patch fixes IM for embedded (ie galeon 1.3.2).. I'm not 100% sure
it is the right way to fix it.. But we need to create a context for embedded
component and use it for children of this component.
Attachment #110562 - Flags: review?(blizzard) → review-
Attachment #116187 - Flags: review?(blizzard)
Yes, the current IMEGetShellWindow() always returns NULL in GTKMozEmbed.
We need to modify IMEGetShellWindow() to return the highest - top parent
nsWindow like widget/src/gtk.

For ic creation, I want to move the creation from CreateNative() to SetFocus(),
see bug 189880. So, I want to correct IMEGetShellWindow() for both Mozilla
and GTKMozEmbed. It should return the top parent nsWindow.

Let me try to put the codes of bug 189880 together to here,

- IMECreateContext() is called in NativeCreate() for
  toplevel and dialog for Mozilla, also child
  with parentGtkContainer for gtkembed

- I have tried to put the creation into SetFocus() but
  gtk+2.0.6 on RedHat8 causes error (bug 194186), so I keep
  creation codes in NativeCreate() (see XIM_CREATE_IC_AT_FOCUS)

- IMEGetShellWindow() now gets the most parent nsWindow
  This works for gtkembed

Frederic, Robin, could you review and try this patch please?
*** Bug 189880 has been marked as a duplicate of this bug. ***
Comment on attachment 116397 [details] [diff] [review]
corrected creation codes for im context (from bug 189880)

katakai,

The functionality of the patch seems ok for me. But I think we can arrange the
xim code a little.

>@@ -656,21 +589,30 @@
>         return NS_OK;
>     }
> 
>+#ifdef USE_XIM
>+    if (mWindowType == eWindowType_child && !mIMEShellWindow) {
>+        IMEGetShellWindow();
>+    }
>+#endif
>+

We may move this into IMESetFocus at the beginning if the im context is created
at SetFocus. This could eliminate some "if".

>     // If there is already a focued child window, dispatch a LOSTFOCUS
>     // event from that widget and unset its got focus flag.
>-    if (gFocusWindow)
>+    if (gFocusWindow) {
>+#ifdef USE_XIM
>+        // If same ic is focused, do not call LoseFocus()
>+        if (mIMEShellWindow != gFocusWindow->mIMEShellWindow) {
>+            gFocusWindow->IMELoseFocus();
>+        }
>+#endif
>         gFocusWindow->LoseFocus();
>+    }

We may move the call of IMELoseFocus() into LoseFocus instead of adding one at
each of it.

>@@ -1516,6 +1447,9 @@
> 
>  foundit:
> 
>+#ifdef USE_XIM
>+    gFocusWindow->IMELoseFocus();
>+#endif
>     gFocusWindow->LoseFocus();

same as last comment
Attached patch updated path (obsolete) — — Splinter Review 
Thank you for comment, Robin.

I've moved IMEGetShellWindow() to IMESetFocus(), and
moved IMELoseFocus() to LoseFocus().
Attachment #110562 - Attachment is obsolete: true
Attachment #116187 - Attachment is obsolete: true
Attachment #116397 - Attachment is obsolete: true
Comment on attachment 116527 [details] [diff] [review]
updated path

Blizzard,

could you review the patch please?

This patch contains the changes for Makefile.in to enable USE_XIM.
Attachment #116527 - Flags: review?(blizzard)
Hi katakai-san. Probably this is trifle, but I wonder why you use both 'NULL'
and 'nsnull'. According to the Coding Style Guideline, should you use only
nsnull (or 0)?
>+void
>+nsWindow::IMECreateContext(GdkWindow* aGdkWindow)
>+{
>+    PLDHashEntryHdr* hash_entry;
>+    nsXICLookupEntry* entry;
>+    GtkIMContext *im = gtk_im_multicontext_new();
>+    if (im) {

And this is also slight thing (and seems not your code), are this |hash_entry|
and |entry| "if (im)" block local?
*** Bug 196243 has been marked as a duplicate of this bug. ***
*** Bug 194820 has been marked as a duplicate of this bug. ***
Attached patch Hybrid patch (obsolete) — — Splinter Review 
I'm having the problems described in bug 187784, that is I cannot enter any
dead keys in Mozilla since 1.3b.

I tried the other patches listed here, and none would do. I tried the latest
(patch 116527) and it doesn't apply cleanly.

What I tried was to reuse the patch 116397 and add the Makefile.in patch from
the latest updated patch. The resulting patch is attached. This makes the
mozilla-devel-gtk2 FreeBSD port compile cleanly on 5.0-RELEASE, and fixes the
bug: I'm able to enter dead keys properly.

Was that last patch suppose to apply correctly?
*** Bug 197041 has been marked as a duplicate of this bug. ***
attachment 116527 [details] [diff] [review] works fine for me, in both mozilla and galeon..

And it fixes a crasher some people were seeing with my version of the patch (see
bug #197041).
Do we have a patch yet that works for everybody?  I'm itching to get this into
the tree.
attachment 116527 [details] [diff] [review] works fine here too, using phoenix from trunk. (RH8+gnome2.2)
I've been using Mozilla 1.3 (branch) patched with attachment 116527 [details] [diff] [review] for one week
now, and it works fine.
attachment 116527 [details] [diff] [review] works fine to me too. (patched to 1.3 release)
*** Bug 197445 has been marked as a duplicate of this bug. ***
*** Bug 176713 has been marked as a duplicate of this bug. ***
*** Bug 197594 has been marked as a duplicate of this bug. ***
One concern for enabling XIM is that I'm seeing the bug 194186
with gtk+2.0.6 of RedHat 8.0. I believe the problem is in
gtk+2.0.6 because I'm seeing the same problem with gtk+2.0 apps
on RedHat8.0.

Try the following on RedHat 8.0,
1. start gnome-search-tool in Japanese locale
2. Just click on "Advanced" tab
  => crashed with the following error,

(gnome-search-tool:10805): Gtk-WARNING **: Loading IM context type 'xim' failed

The same problem happens on Mozilla with the patch,

1. start Mozilla
2. start Composer
3. type something
4. Try to quit the composer

   => Mozilla crashed with XIM error

How about your environment? Is this problem reproducible
on your environment? It seems that Mozilla crashed when
tried to open new dialog for confirmation.

I'm seeing this problem only with gtk+2.0.6 of RedHat8.0
and I've never seen this with gtk+2.2.1.

The crash in #50 is occured on my RedHat Linux 8.0.

In my mozilla that built with the attachment 116527 [details] [diff] [review], I can input Japanese
characters via kinput2 properly only when 
  1. no kana -> kanji conversion is needed (input kana chanracter and type the
enter key).
   or
  2. conversion candidate was selected with cursol key only.

If I want to select the conversion candidates from the candidate selection
window, kinput2 never return from 'ichiran' mode to 'a (kana input)' mode.

This problem also occures in gtk2 application including gnome-terminal, gedit,
and gnome-search-tool. So it depends on RedHat Linux8.0 that why this bug is not
fixed on RedHat Linux8.0.
(And the bug in RHL8.0 is very critical for all the Japanese users.)
attachment 116527 [details] [diff] [review] works for me too. Applied to mozilla 1.3.
Blocks: 197980
*** Bug 174058 has been marked as a duplicate of this bug. ***
*** Bug 187784 has been marked as a duplicate of this bug. ***
*** Bug 197980 has been marked as a duplicate of this bug. ***
*** Bug 195028 has been marked as a duplicate of this bug. ***
Attached patch patch (obsolete) — — Splinter Review 
This patch cleans a lot of stuff.  There are style changes here and the use of
the hash table has been eliminated since we didn't really need it.
Attachment #116527 - Attachment is obsolete: true
Attachment #116566 - Attachment is obsolete: true
So, I've seen a rather serious problem in both the original patch and the patch
I just uploaded.  When you use the candidate window in Japanese, it's pretty
easy to get mozilla wedged into a state where it won't take key presses at all.
 Has anyone else seen this?  I suspect that focus when the candidate window is
closed isn't getting set back to the right place.
Blizzard, now when you say it.
I've been running with the patch for a week or so.
(with phoenix from HEAD)
A couple of time the last few days I've noticed this strange lockup. I'm not
sure how to trigger it though.
blizzard,
what you see might be the bug 194179 .
Blizzard,

please put window->IMEComposeEnd() after IMEComposeText()
in IM_preedit_changed_cb(), which was in attachment 116527 [details] [diff] [review].
I'm seeing a problem on ATOK X without the line.

 void
 IM_preedit_changed_cb(GtkIMContext *context,
...
     if (!preedit_string || !*preedit_string) {
         window->IMEComposeStart();
         window->IMEComposeText(NULL, 0, NULL, NULL);
+        window->IMEComposeEnd();
         return;
     }
And please use #ifdef USE_XIM for IMECreateContext().

+#ifdef USE_XIM
         // We create input contexts for all containers, except for
         // toplevel popup windows
         if (mWindowType != eWindowType_popup)
             IMECreateContext();
+#endif
Attached patch patch (obsolete) — — Splinter Review 
Another attempt at fixing this.  This uses the default processing on key events
to determine if we should do XIM processing or not.  This is probably the
closest that we'll get to having something that's correct.

Here's the way that it works:

1. It keeps track if we've started doing preediting.  There are two ways to
triggers this: if someone calls the preedit_begin callback or someone calls
preedit_changed.  A COMPOSE_START event will be sent in this case.

The default gtk2 event handler does not use preedit_begin or preedit_end, but
kinput2 does use them.

2. If we're not in preediting mode then we let key press events get handled
before XIM gets to see the events.  This lets key accelerators work properly.

3. If we are in preediting mode then XIM gets to see the event before key
events are delivered.

This patch tries to balance the calls to StartComposeIME and EndComposeIME so
we don't call them for every preedit_changed callback.	Hopefully this
shouldn't cause any problems.  I tested it as well as I can here.

There's one known problem with this patch and that's the fact that there's a
key binding for shift-space so kinput2's candidate window doesn't come up.  If
you add a jump to the IC processing in OnKeyPressEvent() when shift-space is
pressed you can see the patch work.  Right now I'm pretty tired so I'll look
for it later.
Attachment #117924 - Attachment is obsolete: true
No response?
I can still reproduce the bug I described in comment #40 with a mozilla-1.3b
build patched with attachement 119022. Actually, now I can enter dead keys
("^`", etc) but I cannot make those "apply" on other keys and make (say) a "è".
So the bug still stands for me. :( I'll try to take a look at the code itself
but I haven't got much time these days..
attachment 119022 [details] [diff] [review] works with me with the lastest trunk on Solaris8 for chinese
locale.
Crap, you're right.  Dead keys don't work.  Back to the drawing board.
Once again, the "hybrid patch" (attachment 116566 [details] [diff] [review]) I submitted works for me.
I've been running a fine mozilla 1.3b build with that patch for weeks now
without any problems.
OK, here's a rundown of my current understanding of where we stand.

o The input method must see the key events before they are sent into the layout
engine.  The last patch I posted just checked the event status to see if a key
event was used, and then passed it on to XIM if it wasn't.  Because of dead
keys, this isn't going to work.  The 'e' key will be used, even it's part of a
dead key combination.  I don't see a way around this.  XIM has to see the events
before they are passed on.

o Menu accelerators are geared off of key press events, not compose events.  And
I'm pretty sure that accelerators can also be found on places like text areas,
not just off of menus.  And since accelerators take precidence over both XIM and
standard DOM events, they need to actually be processed before XIM gets to see them.

o Then there's the scripts problem.  DOM scripts expect to see key events
structured like this:

Key Down
Key Press
Key Press (repeat)
Key Press (repeat)
Key Up

so anything that isn't sent through XIM needs to be sent via the usual method so
that various scripts get the proper events.

I think that in order to fix this correctly, we need to add an event type (as
described below.)

When you get a key press event:

1. Send an accelerator text event.  Only accelerators and UI bits get this
event.  This would include text areas, menus, etc.  I'm not sure how hard this
would be to add. (NS_KEY_ACCEL?)  This would not include typeaheadfind since
that can actually use XIM.

2. Pass the key event to XIM.  We would need to use the method used in the
original patch here to see if XIM modified the event so that we could get DOM
events working.

3. Send the standard NS_KEY_DOWN/NS_KEY_PRESS events.

The big unknown for me is how to hook into the eventlistenermanager to send the
accelerator event and if we've already got infastructure for the various
components to be able to seperate standard key press events from accelerator events.
I had some problems with the hybrid patch.  Some accelerators didn't work.
Which accelerators don't work? Any examples I could try to reproduce?
I think the problem that I had was the 'm' key that marked mail as read/unread
in mail/news.  But it's been a while.
You might want to double-check this, since I can reliably use the 'm' key to
mark messages as read.

So far, I haven't heard of any problems with my patch. ;)
I think Chris was talking about the "Mark all mails as read" accelerator, ie
Ctrl-Shift-C :))

I haven't tested hybrid patch yet so I can't confirm/deny if it works..
Ah darn.. you're right, the C-M-c key accelerator doesn't work. :(
You may want to give attachment 116527 [details] [diff] [review] another try. Ctrl+Shift+C works fine for
me despite that it also invokes the XIM. I guess the reason you can't get it
applied is because it doesn't include the file paths. After adding the file
paths it applies fine, and still applies with recent nightly snapshots of the trunk.
[grunt] hmm.. ok, I guess I should have tried to apply that patch with a nightly
snapshot earlier. [sigh] back to that hours-long compilation again. :)
for the ctrl-shift issue, please see bug 186789. It is due to an ISO standard.
Attached patch final patch? — — Splinter Review 
OK.  This patch let XIM be the one ring to rule them all.  Assuming that we can
get the key bindings fixed, I'm going to check this in.
Attachment #119022 - Attachment is obsolete: true
Last chance.  If there are no comments, I'm checking it in.
Just tested latest patch in 1.4a : works fine in mozilla.. I haven't tested yet
in embedded apps (galeon) but from reading the code, it should work fine..
Works in both Mozilla and embedded (Epiphany) here. 
OK.  Checked in.
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
*** Bug 201376 has been marked as a duplicate of this bug. ***
*** Bug 203370 has been marked as a duplicate of this bug. ***
*** Bug 203347 has been marked as a duplicate of this bug. ***
*** Bug 203424 has been marked as a duplicate of this bug. ***
Bug still here, Mozilla 1.4a (RPMs got from ftp.mozilla.org), RedHat 8.0, locale
pt_BR. Maybe I should wait for 1.4b to get the problem fixed?
1.4b has been out for a while?
*** Bug 203790 has been marked as a duplicate of this bug. ***
I noticed that in mozilla 1.3 this patch apparently also
cured bug #194179 (as I no longer got weird lockup/lose 
of cursors in 1.3). But now, in mozilla 1.3.1, where I see
this (i.e. 119591) patch was not merged into main source tree,
the problem of cursor lockup in text input fields was strongly
back (even in normal 8859-1 pages and without japanese charsets
or locales), either if you apply or not this patch. Any of you noticed this?
Hi people, 
 
Is there any hope of solution for those who cannot install sources and apply 
patches (i.e. are limited to install binary RPMs) ? This bug is really 
annoying for those who must use accents. 
 
Rafael 
 
 
 
This has been in rpms for quite a while.
which rpms for rh9(gtk etc)? 
Comment on attachment 116187 [details] [diff] [review]
Fixed patch for GTKMozEmbed

removing obsolete review request
Attachment #116187 - Flags: review?(blizzard)
Comment on attachment 116527 [details] [diff] [review]
updated path

removing obsolete review request
Attachment #116527 - Flags: review?(blizzard)
So this solves the dead key problem?
In www.mozilla.org the 1.4 download still has the bug.. The tilde problem is
there; Anyway I downloaded the rpm from

http://speakeasy.rpmfind.net/linux/RPM/rawhide/1.0/i386/RedHat/RPMS/mozilla-1.4-12.i386.html

And there it is fixed; how come the official dwnld is still bugged?

--

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

Attachment

General

Creator:
Created:
Updated:
Size: