Closed Bug 345010 Opened 18 years ago Closed 13 years ago

Flash plugin's use of TSM calls can disable keyboard input in FF (trunk and 1.8 branch)

Categories

(Core Graveyard :: Plug-ins, defect)

Product:
Core Graveyard
Component:
Plug-ins
Platform:
PowerPC
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: smichaud, Unassigned)

References

(
URL
)

Details

(Keywords: inputmethod)

Attachments

(1 file)

Traces of calls to ActivateTSMDocument() and DeactivateTSMDocument()
29.46 KB, text/plain
Details 
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.)
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).
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.

> and to show that an incorrectly set TSM document need not be the fault of the
> Java Embedding Plugin :-)

hahaha!
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.
I'm open to suggestions for fixing this and bug 318139.
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.
(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.

> 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.)

> 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.

We're getting kEventWindowActivated on window B but not calling ActivateTSMDocument for doc B?
> 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.

>> 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.)

A similar sounding report has been made at bug 355071.

I installed Flash Player 9 and was no longer able to reproduce this bug.  Can anyone else confirm?
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.

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???
(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 :-)

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!

Steven: Can this be marked fixed/worksforme ?
> Steven: Can this be marked fixed/worksforme ?

Yes, I think so.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: