29065 - IMEText's Decoration isn't updated when losing input focus

Status: VERIFIED FIXED

(Core :: DOM: Editor, defect, P4)

Description

[Masaki Katakai]

IMEText's Decoration isn't updated when losing input focus

Even when the window does not have an input focus, XIM-server wants to
update composing text. It works now, the composing text is rendered.
But the text decoration such as SELECTION_IME_SELECTEDRAWTEXT and
SELECTION_IME_RAWINPUT isn't effected.

It seems that nsTextFrame::PaintUnicodeText() does not render any text
decoration (selection) when document of the input field does not have
an input focus. In the case, 

   displaySelection = doc->GetDisplaySelection();

returns PR_FALSE and PaintTextDecorations() just draws text as normal
decoration.

I don't think this behavior is a bug. But when the text decoration sent
by NS_TEXT_EVENT from IMEs, the decoration needs to be rendered for IMEs
even the window does not have an input focus.

patch:

A patch for nsEditor.cpp is available in the attachment. I'm not sure
it's right fix, but it can solve this problem. If action is kOpInsertIMEText
(NS_TEXT_EVENT is sent from IMEs with composed string),
call SetDisplaySelection(PR_TRUE) to force PaintUnicodeText() renders
text decoration. Please review.

background:

Candidate window of some XIM-server (kinput2 and Sun's atok12) on UNIX
platform grabs an input focus when it maps. After a choice is selected
and the candidate window is closed, the input focus will get back to
the original input field. During the operation, the window that has
original input field does not have the input focus but XIM-server wants
to update the composing text.

For example, atok invokes the candidate window by space and space.
Some candidates are displayed on the Candidate window and the first
candidate is reversed to indicate the default candidate. Next space key
will move the reverse to the 2nd candidate. At the same time, atok want
to change the composing text to the 2nd candidate on the original input field.
The composing text should be drawn with SELECTION_IME_... decoration to
indicate that the text is being composed. But due to this problem, the text
is rendered as normal text (SELECTION_NORMAL). This problem happens on
Solaris 8/atok12.

Comment 1

[Masaki Katakai]

Attachment: patch for nsEditor.cpp

Comment 2

[Kathleen :Brade]

Mike--please look at this patch as soon as you finish your current PDT+ bugs.

Comment 3

[rubydoo123]

setting to New

Comment 4

[mjudge]

hmm looking at it let me set this bug to m16 right now..

Comment 5

[rubydoo123]

m17

Comment 6

[mjudge]

will look at patch now.

Comment 7

[Hidetoshi Tajima]

comment updated for reminder.

Comment 8

[rubydoo123]

assigning to anthony to look at the patch, this has been around way too long, 
let's get this reviewed and back to the owner so they can get it checked in if 
this reviews well.

Anthony, you may want to ping kin for help

Comment 9

[Masaki Katakai]

http://bugzilla.mozilla.org/show_bug.cgi?id=52416

is similar problem. Now commit string does not work
when the field does not have an input focus. Please
work with Kin.

Comment 10

[anthonyd]

adding kin to the cc list.

anthonyd

Comment 11

[rubydoo123]

it's going to have to wait until post-rtm

Comment 12

[Donnie Cranford]

Reassigning bug to myself for review and patch of nsEditor.cpp
Wll get back in touch with [e-mail] when patch is completed and
verified that it works.

Comment 13

[Donnie Cranford]

The patch that comes with this bug is from february....and does not fit into
anything that nsEditor.cpp has become today. I also am not seeing this problem
on my Solaris builds. I am leaving open and would like someone to verify that
this is no longer a problem and well verify it WORKSFOR ME

Comment 14

[Masaki Katakai]

Hi Donnie, Thank you for looking into this problem.
Yes, actually it seems that this problem does not happen on the current build.
I agree this problem will be closed as WORKSFORME.

Text decoration is OK, but drawing text and comming text don't work due to
http://bugzilla.mozilla.org/show_bug.cgi?id=52416.

Comment 15

[Donnie Cranford]

Acording to the engineers at Sun and also my testing this bug is not around
anymore, so we have verified WORKSFORME so im marking it fixed

Comment 16

[sujay]

can someone please mark this bug VERIFIED-FIXED ? thanks.

Comment 17

[Katsuhiko Momoi]

ji, can we ask you to look at this? If you can't, let's pass it
on to teruko.

Comment 18

[Masaki Katakai]

I've verified this on Linux and Solaris. Can I mark it as VERIFIED?

Comment 19

[Kathleen :Brade]

someone should test Mac...
ji or teruko--can you test this on Mac?

Comment 20

[ji]

I can't reproduce the problem with Mac 2000103008-mn6 build. Marked it as 
verified.