133211 - Mozilla gtk embeded XIM bug - Candidate list window flushes to disappear

Status: VERIFIED FIXED

(Core :: Internationalization, defect)

Description

[Yukihiro Nakai]

When I use mozilla + 0.9.9 + galeon 1.2.0 + kinput2(canna) + sawfish 1.0.1,
kinput2's candidate list window flushes to disappear.
It doesn't occur on Mozilla itself, but does on embedded component.
(galeon)

Comment 1

[Yukihiro Nakai]

See also http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=61847

Comment 2

[Masaki Katakai]

Is it possible to set "never-focus" to Kinput2 candidate window
in sawfish window manager ?

like 

(custom-set-typed-variable (quote match-window-profile) (quote ((((WM_CLASS .
"Kinput2/selectionShell")) (never-focus . t) (ignored . t) (window-list-skip .
t) (skip-tasklist . t)))) (quote match-window) (quote sawfish.wm.ext.match-window))

I strongly recommend the setting because there are still some
focus problems such as bug 52416. Mozilla assumes input focus
is always in Mozilla itself while composing characters.

Comment 3

[Masaki Katakai]

When losing the input focus, Mozilla calls nsWindow::ResetInputState(),
the method should reset the state of input field.

However, for Linux/UNIX, candidate window of some IMEs
grabs input focus so this method is being called.
To ignore the event, we've put mIMEIsBeingActivate flag
not to reset input state. 

    // while being called for NS_ACTIVE and NS_DEACTIVATE,
    // ignore ResetInputState() call
    if (mIMEShellWindow->mIMEIsBeingActivate == PR_TRUE) {
      return NS_OK;
    }

It seems that NS_ACTIVE and NS_DEACTIVATE are not passed
to Mozilla embeded when we use galeon.

Comment 4

[Yukihiro Nakai]

Setting Kinput2/selectionShell to never focused by sawfish works.
This problem also occurs on WindowMaker, kde window manager.
It doesn't on twm, fvwm2.

Comment 5

[Masaki Katakai]

nsWindow::ResetInputState() is called from Editor::Blur(),
which is caused by my changes as bug 81356. I understand
this is correct behavior but it cauases problem only in
galeon.

Program received signal SIGABRT, Aborted.
0x407e68c1 in kill () from /lib/libc.so.6
(gdb) where
#0  0x407e68c1 in kill () from /lib/libc.so.6
#1  0x401bc09b in raise () at eval.c:41
#2  0x407e7e42 in abort () from /lib/libc.so.6
#3  0x40ffb651 in nsWindow::ResetInputState ()
   from /usr/lib/mozilla/components/libwidget_gtk.so
#4  0x4160553f in nsEditor::ForceCompositionEnd ()
   from /usr/lib/mozilla/components/libeditor.so
#5  0x415fe67b in nsTextEditorFocusListener::Blur ()
   from /usr/lib/mozilla/components/libeditor.so
#6  0x40d01c70 in nsEventListenerManager::HandleEvent ()
   from /usr/lib/mozilla/components/libgkcontent.so
#7  0x40e94d42 in nsGenericElement::HandleDOMEvent ()
   from /usr/lib/mozilla/components/libgkcontent.so
#8  0x40d3e5e7 in nsHTMLInputElement::HandleDOMEvent ()
   from /usr/lib/mozilla/components/libgkcontent.so
#9  0x40d056e9 in nsEventStateManager::PreHandleEvent ()
   from /usr/lib/mozilla/components/libgkcontent.so
#10 0x4138e394 in PresShell::HandleEventInternal ()
   from /usr/lib/mozilla/components/libgklayout.so
#11 0x4138e248 in PresShell::HandleEvent ()
   from /usr/lib/mozilla/components/libgklayout.so
#12 0x41520754 in nsViewManager::HandleEvent ()
   from /usr/lib/mozilla/components/libgkview.so
---Type <return> to continue, or q <return> to quit--- 
#13 0x41515ef8 in nsView::HandleEvent ()
   from /usr/lib/mozilla/components/libgkview.so
#14 0x4151fda2 in nsViewManager::DispatchEvent ()
   from /usr/lib/mozilla/components/libgkview.so
#15 0x41211887 in GlobalWindowImpl::Deactivate ()
   from /usr/lib/mozilla/components/libjsdom.so
#16 0x400263ac in EmbedPrivate::ChildFocusOut () at eval.c:41
#17 0x40023709 in handle_child_focus_out () at eval.c:41
#18 0x40559fbc in gtk_marshal_BOOL__POINTER () at eval.c:41
#19 0x4058d916 in gtk_handlers_run () at eval.c:41
#20 0x4058cc3d in gtk_signal_real_emit () at eval.c:41
#21 0x4058a9f5 in gtk_signal_emit () at eval.c:41
#22 0x405c50e9 in gtk_widget_event () at eval.c:41
#23 0x405cded4 in gtk_window_focus_out_event () at eval.c:41
#24 0x40559fbc in gtk_marshal_BOOL__POINTER () at eval.c:41
#25 0x4058cc7d in gtk_signal_real_emit () at eval.c:41
#26 0x4058a9f5 in gtk_signal_emit () at eval.c:41
#27 0x405c50e9 in gtk_widget_event () at eval.c:41
#28 0x40558fe4 in gtk_main_do_event () at eval.c:41
#29 0x40fedf1f in handle_gdk_event ()
   from /usr/lib/mozilla/components/libwidget_gtk.so
#30 0x40610e4f in gdk_event_dispatch () at eval.c:41
#31 0x406437f3 in g_main_dispatch () at eval.c:41
---Type <return> to continue, or q <return> to quit--- 
#32 0x40643dd9 in g_main_iterate () at eval.c:41
#33 0x40643f8c in g_main_run () at eval.c:41
#34 0x40558803 in gtk_main () at eval.c:41
#35 0x080964f1 in main () at eval.c:41
#36 0x407d5237 in __libc_start_main () from /lib/libc.so.6
(gdb) 

Comment 6

[Masaki Katakai]

Attachment: proposed path; not to call reset input state when the widget does not have focus

Comment 7

[Masaki Katakai]

There is one difference between galeon and Mozilla, which
is ResetInputState() is called when there is no focus on
the widget on galeon. I understand we should not call
ResetInputState() when no focus. This change will not
reproduce the problem of bug 81356.

Nakai-san, could you please test the patch?

I'll also test Mozilla here.

Comment 8

[Yukihiro Nakai]

This patch works well with kwin(KDE window manager), windowmaker, sawfish.

Comment 9

[Masaki Katakai]

Thank you very much for testing,

Now requesting review...

Comment 10

[Frank Tang]

Comment on attachment 76142 [details] [diff] [review]
proposed path; not to call reset input state when the widget does not have focus

r=ftang. make sense

Comment 11

[Christopher Blizzard (:blizzard)]

Comment on attachment 76142 [details] [diff] [review]
proposed path; not to call reset input state when the widget does not have focus

sr=blizzard

Comment 12

[Asa Dotzler [:asa]]

Comment on attachment 76142 [details] [diff] [review]
proposed path; not to call reset input state when the widget does not have focus

a=asa (on behalf of drivers) for checkin to the 1.0 trunk

Comment 13

[Masaki Katakai]

patch has been checked into 1.0 Trunk.

Comment 14

[Rui Xu]

Hi Nakai-san,
Could you please verify with the latest build to see if it is still 
reproducible? Thank you!

Comment 15

[Rui Xu]

Mark bug as VERIFIED. please reopen if see it again.