15708 - [dogfood]IME inoperative on mac after window loses focus once.

Status: VERIFIED DUPLICATE of bug 7571

(Core :: Layout, defect, P1)

Description

[Joe Francis]

To reproduce:

launch the editor on a mac equipped with IME support and a language kit.  While
in editor, set the language to japanese, and set the character set appropriately.
Type some text (IME works here).  Now bring the finder to the forground.  Now
bring the editor back to the forground.  Further typing does not generate IME
events.  If you reselect Japanese, further typing will bring up the ime input
field supplied by macos instead of allowing inline ime input.

This bug is a blocker for me to fix ime support in the editor (I cant debug ime
if ime ceases to function everytim I bring a debugging window to the front).

Comment 1

[Joe Francis]

setting milestone/priority

Comment 2

[tague]

unfortunately, there is nothing that i can do about this.  this is a side effect
of how TSM is implemented and how it interacts with the debugger.  you just have
to be careful about what windows get brought to the front and have to use
different techniques to debug.  if it still isn't working, we can try debugging
on windows -- windows has the same problem but it's not as pronounced as on the
Mac.

Comment 3

[Joe Francis]

this is a real bug.  this is not a debugger affair.  Anytime the user switches
out to the finder and comes back, ime is broken.

Comment 4

[leger]

Clearing Invalid resolution due to reopen.

Comment 5

[Frank Tang]

jfrancis , I believe this is a bug, but can you work around by putting printf of
the variable you want to check before we fix this ?

Comment 6

[tague]

someone changed the event handling mechanism, so Active Events are no longer
calling nsMacMessagePump::HandleActivateEvent(), which has the code responsible
for Activating/DeactivatingTSM Documents, but didn't carry over the existing TSM
code.

If someone can point me to docs or a description of where/how we are handling
Activate/Deactivate events; I'll go add it back

Comment 7

[tague]

reassigning to widget group

Comment 8

[Peter Trudelle]

This is not an XPToolkit widget. changing component to editor, reassigning.

Comment 9

[buster]

changed component to layout since trudelle doesn't seem to think it's his.
The code is in mozilla/widget/src/mac.
The code was most recently changed by pierre, so assiging to him.  Tauge, please
work with Pierre to either fix this or find out who really owns it.

Comment 10

[tague]

I don't understand Trudelle's comment that this "isn't an xpwidget."  This bug
has nothing to do with ender, it's about problems in the widget/src/mac
directory -- specifically changes to Macintosh native platform event handling.
If Trudelle's group doesn't own this, who does?

Comment 11

[saari (gone)]

No this isn't xptoolkit per se. Pierre is the first choice, but he is working on
CSS full time now. dcone is next in line, but realistically, I'll probably end up
with this bug anyway.

Comment 12

[saari (gone)]

Don't you mean nsMacEventHandler::HandleActivateEvent() not  nsMacMessagePump?

nsMacEventHandler::HandleActivateEvent() is definitely getting called, if it
wasn't, then menus wouldn't work

Comment 13

[Pierre Saslawsky]

I am available to help you fix bugs in the code I previously owned but I can no
longer take ownership for them. Reassigning to saari.

Chris, I'll stop by (or give me a buzz if I don't). I think I know what the
problem is.

Comment 14

[leger]

Putting on the PDT+ radar

Comment 15

[tague]

any update on this?  this is keeping jfrancis from getting other work done.

Comment 16

[Joe Francis]

After chatting with Tague some about this, I played around with it some.  The
activate and deactivate events seem to be getting handled (Tague had theorized
that they might not be and that could cause the behavior).

I don't know enough about the mac Text Services Manager to know why it is getting
confused.  We could surely use some expertise on this.  I can try to work around
it, but it is a dogfood issue for IME support in the browser and messenger.

Comment 17

[Pierre Saslawsky]

This issue has been around for quite a while now. It's a dup of #7571. Look under
#7571 for more info.


*** This bug has been marked as a duplicate of 7571 ***

Comment 18

[tague]

This isn't a duplicate of 7571.  This is a problem that surfaced within the past
month due to changes in the way that focus and event dispatch are interacting.

The old ActivateEvent handlers which contain the TSM handling code are only
getting called once, when the Mac window is created ; after that something else
is handling Activate Events.

Comment 19

[Pierre Saslawsky]

jfrancis was writing on 10/22/99 15:45 that activate events were handled and that
he was working with tague on the issue. I don't understand why they disagree now.

Comment 20

[saari (gone)]

Are we talking about nsMacEventHandler::HandleActivateEvent() getting called, or
something else?

BTW, I'm about to thwack the focus/event dispatching so I'd like to understand
what the problem is before I potentially make it worse...

Comment 21

[Pierre Saslawsky]

I checked again today and I confirm that nsMacEventHandler::HandleActivateEvent()
and then ActivateTSMDocument() and DeactivateTSMDocument() are getting called on
activate and deactivate events.

But now the question is: do we also need to call ActivateTSMDocument() and
DeactivateTSMDocument() on suspend/resume events?

Comment 22

[David Hyatt]

Closing this one as a dup of 7571

*** This bug has been marked as a duplicate of 7571 ***

Comment 23

[leger]

Marking Verified as Dup.

Comment 24

[Joe Francis]

Woohoo!  Thanks to whoever fixed this.