Last Comment Bug 345010 - Flash plugin's use of TSM calls can disable keyboard input in FF (trunk and 1.8 branch)
: Flash plugin's use of TSM calls can disable keyboard input in FF (trunk and 1...
Status: RESOLVED FIXED
: inputmethod
Product: Core
Classification: Components
Component: Plug-ins (show other bugs)
: Trunk
: PowerPC Mac OS X
: -- normal (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
http://www.rogerdean.com/
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2006-07-17 21:11 PDT by Steven Michaud [:smichaud] (Retired)
Modified: 2011-08-19 15:08 PDT (History)
9 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Traces of calls to ActivateTSMDocument() and DeactivateTSMDocument() (29.46 KB, text/plain)
2006-07-17 21:16 PDT, Steven Michaud [:smichaud] (Retired)
no flags Details

Description Steven Michaud [:smichaud] (Retired) 2006-07-17 21:11:00 PDT
As noted at bug 318139, the Flash plugin supports IME input -- so it
has its own "TSM document", which it sets (using
ActivateTSMDocument()) and unsets (using DeactivateTSMDocument()) at
the appropriate times.  Firefox also supports IME input, and each
browser window has its own TSM document.  But Firefox doesn't save and
restore its TSM document(s) before and after plugin code runs.  So the
Flash plugin has also taken on this task -- it also tries to save and
restore the browser's TSM document(s).

But there are problems with this, due to the fact that the browser TSM
document that the Flash plugin saved isn't necessarily the one that
needs to be restored (when the time comes for that to happen).

I've found another instance of this kind of trouble.  It doesn't cause
a crash, but it does disable keyboard input in recent builds of
Mozilla.org Carbon-based browsers (e.g. Firefox), on the trunk and 1.8
branch -- which now get all their keyboard input via TSM (from the
kUnicodeNotFromInputMethod Apple event), since the fix for bug 337199
was landed.

If you follow these steps, the TSM document in the second browser
window (DocumentB) will end up being set to NULL -- which disables
text input in all of its text fields.

1) Start Firefox and open two windows -- one with two tabs (DocumentA)
   and one with one tab (DocumentB).
2) Open http://www.rogerdean.com in one of the tabs of DocumentA, and
   click once on the "Roger Dean" Flash object (at the top) to give it
   the keyboard focus.
3) Click on DocumentA's "close button" -- a "Close Tabs" modal dialog
   will appear.
4) Click on the modal dialog's "Close Tabs" button, and the following
   calls will be made to ActivateTSMDocument() and
   DeactivateTSMDocument().  At the end only DocumentB will be open,
   and the current TSM doc will be set to 0x00000000.  No matter which
   of DocumentB's text input fields you click in, you won't be able to
   input any text (and the TSM doc will stay set to 0x00000000).
5) To restore things to normal (i.e. to restore DocumentB's TSM doc to
   its correct value, and to restore text input), click once on the
   desktop and once on DocumentB.

I tested with Firefox 2.0b1 (patched with the fix for bug 344701 and a
bunch of extra debugging output).  But it might be more appropriate to
test with a trunk or 1.8 branch nightly dated 2006-07-17 or later
(which will include the fix for bug 344701).

If you test with earlier versions, bug 344701 may interfere with your
results.

I'm not sure anything can be done about this bug until bug 318139 is
fixed.  I'm mainly opening this bug for the record ... and to show
that an incorrectly set TSM document need not be the fault of the Java
Embedding Plugin :-)  (In fact I spent three days tracking this bug
down, after having assumed that it must somehow be caused by the JEP.)
Comment 1 Steven Michaud [:smichaud] (Retired) 2006-07-17 21:16:35 PDT
Created attachment 229612 [details]
Traces of calls to ActivateTSMDocument() and DeactivateTSMDocument()

Here are stack traces of the calls that were made to
ActivateTSMDocument() and DeactivateTSMDocument(), from the browser
and from the Flash plugin, while following the 5 steps from comment #0
(along with a narrative of how each call changed the current TSM
document).
Comment 2 Steven Michaud [:smichaud] (Retired) 2006-07-17 21:33:08 PDT
I forgot to mention that I tested on OS X 10.3.9, with version 8.0 r24
of the Flash plugin (which seems to be the version currently installed
by Apple's Software Update, on both OS X 10.3.9 and 10.4.7).

And the reason the Flash plugin got mixed up in my JEP results is that
I was testing with a (very interesting) combination of Flash and Java
-- http://www.kaon.com/software/swflash.html.
Comment 3 Mark Mentovai 2006-07-18 08:03:59 PDT
> and to show that an incorrectly set TSM document need not be the fault of the
> Java Embedding Plugin :-)

hahaha!
Comment 4 Michelle Sintov 2006-07-18 09:16:14 PDT
If a better solution could be implemented instead of this TSMDocumentID business, we'd be happy to changeover to that in the Flash Player. Or, if a modification could be made in how the Flash Player uses the TSMDocumentID, we'd be interested in that too.
Comment 5 Mark Mentovai 2006-07-18 09:56:56 PDT
I'm open to suggestions for fixing this and bug 318139.
Comment 6 Michelle Sintov 2006-07-18 10:06:01 PDT
With Safari, bottomline input works with the Flash Player, and the Flash Player doesn't have to do any TSMDocumentID work at all. Perhaps Safari's (presumably in WebKit?) solution could be used in Firefox? Unfortunately, I don't know what that solution is right now so someone would have to investigate.
Comment 7 Steven Michaud [:smichaud] (Retired) 2006-07-18 10:16:32 PDT
(From attachment 229612 [details] -- this is the comment above the last trace,
of a call from the Flash plugin to ActiveTSMDocument())

> DocumentA (two tabs, one containing http://www.rogerdean.com) -- TSM
>   doc 0x00ED830C
> Modal "Close Tabs" dialog above DocumentA -- TSM doc 0x00ED8A58
> DocumentB (one tab) -- TSM doc 0x00ED8EA8
>
> The following call to ActivateTSMDocument() is made on TSM doc
> 0x00ED830C, and results in the current TSM doc being set to
> 0x00ED830C momentarily, then reverting to 0x00000000.  (I'm not
> entirely sure how it "reverts".)

I've discovered what makes the current TSM doc "revert" to NULL after
this step -- the browser makes a call to DeleteTSMDocument() on the
TSM doc for DocumentA.  At this point (the call from the Flash plugin
to ActivateTSMDocument()), DocumentA has already been closed and
DocumentB is active -- so the Flash plugin is setting DocumentB's
current TSM doc incorrectly (to the value for DocumentA).  But the TSM
for DocumentA hasn't yet been deleted -- which must be why the Flash
plugin's call to ActivateTSMDocument() doesn't result in a crash.

I still haven't figured out why there's no call from the browser to
set DocumentB's current TSM doc to 0x00ED8EA8 -- I suppose that's an
artifact of how I got my traces.  When I'm not getting traces, this
call presumably happens just before the Flash plugin's call to set
DocumentB's current TSM doc to 0x00ED830C.
Comment 8 Steven Michaud [:smichaud] (Retired) 2006-07-18 10:35:07 PDT
> I still haven't figured out why there's no call from the browser to
> set DocumentB's current TSM doc to 0x00ED8EA8 -- I suppose that's an
> artifact of how I got my traces.  When I'm not getting traces, this
> call presumably happens just before the Flash plugin's call to set
> DocumentB's current TSM doc to 0x00ED830C.

This call is still missing even when I don't take traces.  This must
have something to do with clicking on the Flash object in step 2
(thereby giving it the keyboard focus).  This might be a bug in the
browser.

(The problem I report here doesn't happen if, in step 2, you make sure
the Flash object doesn't have the focus.  Then (of course) the Flash
plugin doesn't make any TSM calls.  And the browser does make a call
to ActivateTSMDoc() as DocumentB is activated.)
Comment 9 Steven Michaud [:smichaud] (Retired) 2006-07-18 10:41:52 PDT
> This might be a bug in the browser.

The browser does receive a kEventWindowActivated event for DocumentB
-- so the Flash plugin isn't swallowing it.
Comment 10 Mark Mentovai 2006-07-18 10:45:38 PDT
We're getting kEventWindowActivated on window B but not calling ActivateTSMDocument for doc B?
Comment 11 Steven Michaud [:smichaud] (Retired) 2006-07-18 10:58:31 PDT
> We're getting kEventWindowActivated on window B but not calling
> ActivateTSMDocument for doc B?

Yes, that's what my debug info says.  But I haven't tried to find out
why.
Comment 12 Steven Michaud [:smichaud] (Retired) 2006-07-18 11:33:05 PDT
>> We're getting kEventWindowActivated on window B but not calling
>> ActivateTSMDocument for doc B?
>
> Yes, that's what my debug info says.  But I haven't tried to find
> out why.

Err ... I just did a couple more tests (without getting traces, with
the focus in the Flash object at step 2) in which the browser _did_
call ActivateTSMDocument() (with the correct value) when "DocumentB"
was activated.

Maybe I just goofed my previous test ... or maybe the results can go
either way.

(The current TSM doc still ended up being NULL, thanks (presumably) to
the Flash plugin's call to activate the wrong TSM doc (that for
DocumentA), and the browser's subsequent call to delete the TSM doc
for DocumentA.)
Comment 13 Steven Michaud [:smichaud] (Retired) 2006-10-01 17:21:14 PDT
A similar sounding report has been made at bug 355071.
Comment 14 Mint Shows 2006-11-27 20:24:46 PST
I installed Flash Player 9 and was no longer able to reproduce this bug.  Can anyone else confirm?
Comment 15 Steven Michaud [:smichaud] (Retired) 2006-11-28 11:30:45 PST
I installed Flash Player 9 (on OS X 10.3.9) and can still reproduce
this bug every time (following the steps in comment #0).  I also can
still reproduce the problems described in bug 355071 comment #0 and
bug 355071 comment #7.  I tested with Firefox 2.0.
Comment 16 Leah Bannon 2007-01-12 12:38:49 PST
I'm sorry, I'm just a user and I don't understand most of this line of discussion, but I just wanted to say HELP!  This bug is definitely still possible to reproduce.  I just upgraded to FF2.0.0.1 and ANY time I use any sort of flash (which I have the plug-in for up to date) FF starts ignoring all keyboard input from me.  Even after un and reinstalling.  This seems like a HUGE bug to me???
Comment 17 Steven Michaud [:smichaud] (Retired) 2007-01-12 15:07:26 PST
(In reply to comment #16)

I'm working on a fix for this bug at bug 355071.

My fix resolves both bugs to my satisfaction, but it needs to be
reviewed by other programmers familiar with the relevant parts of the
Mozilla.org codebase before it can be "landed" -- i.e. become part of
a Firefox 2.0.0.X release or a "nightly".  Until that happens you
won't be able to download a copy of Firefox 2.0.0.X that contains this
fix.

I _hope_ that my fix can be included in Firefox 2.0.0.2 (when that
comes out) ... but that's by no means certain.

As it happens, my fix deals with two very different areas of the
Mozilla.org codebase.  Almost no-one is familiar with both areas, and
even I'm not very familiar with one of them.  So it's quite important
to find someone to review my code, but it's also quite difficult to
find one who's both qualified and has the time.

When my fix (or a fix) is landed, it will first appear in a
(so-called) "mozilla-1.8 branch" nightly (they're available at the
following URL, and all have names like 2007-01-12-07-mozilla1.8).
These "nightlies" (new ones appear every "night") are early versions
of what will eventually become the next release on the Firefox 2.0.0.X
branch -- currently the next release on this branch will be Firefox
2.0.0.2.  This "branch" is also called the Mozilla 1.8.0.1 branch, and
isn't to be confused with the Mozilla 1.8.0 branch (which concerns
future releases of Firefox 1.5.0.X).  Yes, even I find all this a bit
hard to grasp ... but you've got to know it to be able to find your
way around bugzilla.mozilla.org.

ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/

When a Firefox 2.0.0.X-branch (aka mozilla-1.8 branch) nightly comes
out that does contain my fix (or something like it), I'll post a
notice here.

I'll expect you to download and test it :-)
Comment 18 Steven Michaud [:smichaud] (Retired) 2007-01-22 09:11:57 PST
As I mentioned above, I've been working on a fix for this bug at bug
355071.  The first mozilla1.8-branch nightly to contain my fix
(firefox-2007-01-22-07-mozilla1.8) has appeared at

ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/

Please try it out!
Comment 19 Matthias Versen [:Matti] 2011-08-19 14:15:25 PDT
Steven: Can this be marked fixed/worksforme ?
Comment 20 Steven Michaud [:smichaud] (Retired) 2011-08-19 15:08:43 PDT
> Steven: Can this be marked fixed/worksforme ?

Yes, I think so.

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