Closed Bug 520312 Opened 11 years ago Closed 9 years ago

Silverlight IME: TextBox: Unable to input any East Asian characters in Firefox 3.0 and greater

Categories

(Tech Evangelism Graveyard :: English US, defect, major)

x86
macOS
defect
Not set
major

Tracking

(Not tracked)

RESOLVED INCOMPLETE

People

(Reporter: andy.rivas, Unassigned)

Details

(Keywords: intl)

Attachments

(2 files)

User-Agent:       Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; Trident/4.0; SLCC1; .NET CLR 2.0.50727; .NET CLR 1.1.4322; InfoPath.2; .NET CLR 3.5.21022; .NET CLR 3.5.30729; OfficeLiveConnector.1.3; OfficeLivePatch.0.0; .NET CLR 3.0.30729; MS-RTC LM 8)
Build Identifier: 

On OSX IME broke for Silverlight between version 2 and 3.  East Asian customers will not be able to use IME on Mac due to this issue.  IME works fine on Safari, it just appears to be broken on Firefox.

Reproducible: Always

Steps to Reproduce:
1.Install the Silverlight Runtime http://www.microsoft.com/silverlight/get-started/install/default.aspx
2.Uzip the contens of SilverlightIME.html to your mac
3.Open SilverlightIME.html
4.Click the text box and turn on any East Asian IME
Actual Results:  
Unable to input any character using IME

Expected Results:  
Use IME to input characters


I've pasted a table below that shows the results of some tests we've done and it seems that some change between Firefox 2 and 3 broke Silverlight IME?  We'd like to know what changed between 2 and 3 that could have broke us and what we can do to fix the issue.
 
MacFireFox Version	Flash IME	Silverlight IME
2.x 	                Works	        Works
3.0.1 	                Does not work	Does not work
3.0.10 	                Works	        Does not work
3.5 	                Works	        Does not work
confirm on trunk 20091003031247 on Mac OS X 10.6 with Andy's sample.

Silverlight 3 for Mac OS X doesn't support inline edit of IME.  When I commit IME strings, first byte will be lost.  Also, backspace key doesn't work when Japanese IME is turned on.

I add Nakano-san to CC.
Status: UNCONFIRMED → NEW
Component: General → Widget: Mac
Ever confirmed: true
Product: Firefox → Core
QA Contact: general → mac
Version: unspecified → Trunk
Thank you, Kato-san.

Steven, is there any idea of the cause?
Component: Widget: Mac → Widget: Cocoa
Keywords: intl
QA Contact: mac → cocoa
> Steven, is there any idea of the cause?

Not off the top of my head.

The fact that IME doesn't work on FF 3.0.1, which doesn't have my patch for bug 357670, indicates that patch isn't at fault.

Kinda looks like the Silverlight 3 developers have only just started testing IME with Silverlight 3 on Firefox :-(
> The fact that IME doesn't work on FF 3.0.1

I'm assuming this from the contents of comment #0, and that the "3.0.10" in the summary is a typo.
Next week I'll next further into this.
Assignee: nobody → smichaud
Status: NEW → ASSIGNED
> Next week I'll next further into this.

Next week I'll dig further into this.
Steve,

Have we had a chance to look at this issue?  Do we know whether Flash made some kind of fix between Firefox 3.0.1 and 3.0.10?  They were also broken between these releases.

Thanks
Even in Safari, Silverlight 3 uses "input window" IME, not "inline IME".

Even "input window" IME doesn't work in Firefox 3.0 and above.  But
it's broken in different ways before and after my patch for bug 357670
(which landed in Firefox 3.0.2).

I'd hoped that my patch for bug 508898 might fix (or work around) this
bug -- it doesn't.

It will probably take me some time to debug this.

Andy, I may find that I need more information about how Silverlight's
IME support works internally.  If so I'll ask here.
Summary: Silverlight IME: TextBox: Unable to input any East Asian characters in Firefox 3.0.10 and greater → Silverlight IME: TextBox: Unable to input any East Asian characters in Firefox 3.0 and greater
Steven,

Do we have a status on this?

Thanks
Sorry, I haven't yet been able to get to this.

I'll try to spend some time on it later this week.
Steven,

Can you tell us if there has been any special casing for Flash in the 3.0.10 release?

Thanks
(In reply to comment #12)

> Can you tell us if there has been any special casing for Flash in
> the 3.0.10 release?

Not explicitly.  But I had to do some serious hacking to make things
work properly in Flash -- which at the time (and until Silverlight 3
came out) was the only plugin that claimed to support CJK IME on OS X.

See particularly bug 357670 comment #54.

You should read carefully through my patch for bug 357670, and at
least skim all the comments in that bug.

I still haven't had a chance to get to this bug.  I'm hoping for later
this week.
Andy, is there any way to download earlier versions of Silverlight
than version 3?

I'd like to be able to test with Silverlight 2, but all I have are
copies of different Silverlight 2 betas.
After *much* digging around, I've managed to find the following links
to versions 2 and 3 of the "Silverlight Developer Runtime":

"Silverlight 2 Developer Runtime"
http://go.microsoft.com/fwlink/?LinkID=119973

"Silverlight 3 Developer Runtime"
http://go.microsoft.com/fwlink/?LinkID=150227

I assume these will be adequate for my purposes.

I couldn't find anything equivalent for Silverlight 1 ... but I hope
that's too old to be relevant.

You know, it's *really* annoying when a software publisher hides its
older versions.
For all previous versions of Silverlight.  http://go.microsoft.com/fwlink/?LinkID=92598

This link is actually found in http://www.microsoft.com/silverlight/resources/technical-resources/ but we need to work on SEO.
Thanks!  The first link is exactly what I need.

And yes, you guys do need to make this information easier to find :-)
Andy, your testcase appears to require Silverlight 3.

If I understand correctly, Silverlight 2 didn't support CJK IME on OS
X.  But I'd still like to be able to test with a simple text box that
works with both Silverlight 2 and Silverlight 3.
I'm having terrible trouble running either Firefox or Safari in gdb
while a Silverlight plugin is loaded (in either Silverlight Developer
2 or Silverlight 3).  The app tends to freeze up after hitting a
single breakpoint.  I'm testing on OS X 10.5.8.

I've never seen this before.  Certainly never with any plugin.

Any idea what's going on, Andy?

I notice that the IMETextBox.dll which comes with your testcase is a
DOS/Windows executable (it starts with 'MZ').  Does this mean
Silverlight "apps" run in some kind of interpreter, and could this be
the source of the trouble?
> I notice that the IMETextBox.dll which comes with your testcase is a
> DOS/Windows executable (it starts with 'MZ').

'file' returns the following on it:

IMETextBox.dll: MS-DOS executable PE
  for MS Windows (DLL) (console) Intel 80386 32-bit
This is the way all Silveright applications are built.  The applications include "managed" assemblies that are loaded by the control.  The assemblies are platform agnostic.

I'm going to try to get a dev on this thread to help you with your debugging issue.
(In reply to comment #22)

Thanks.  I imagine Silverlight apps use bytecode, something like Java apps.

(Following up comment #20)

Now I've seen the same problem on OS X 10.6.2.

I've also seen the browser (with Silverlight running) freeze in gdb
without setting (or hitting) any breakpoints at all.

Needless to say, I'm probably not going to be able to help you unless
we can find a way around this.
Gotcha!  This bug is entirely Silverlight's fault.

I've been banging my head against this for some time.  Among other
things I actually figured out how to hook Text Services Manager calls
(like DeactivateTSMDocument()), and how to log a stack trace on each
call (more on this in a later comment).  I also added logging to
Firefox's [ChildView processPluginKeyEvent:] (in ChildView.mm), which
shows that Firefox is sending the correct keystroke information to
Silverlight.

But I forgot to try something really obvious -- set Firefox to use
Safari's user agent string, and see what happens.  Just now I did this
... and it makes the problem go away!

Clearly Silverlight is using a different code path in Firefox, and
clearly it's doing something wrong there.
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → INVALID
I'm gonna reopen this and kick it to TE, then, since it's pretty important that Silverlight not be broken in Firefox.
Assignee: smichaud → english-us
Status: RESOLVED → REOPENED
Component: Widget: Cocoa → English US
Product: Core → Tech Evangelism
QA Contact: cocoa → english-us
Resolution: INVALID → ---
Version: Trunk → unspecified
Here's how to set Firefox to use Safari's user agent string:

1) Enter about:config in the Location bar.

   If prompted,	click on the "I'll be careful, I promise!" button.

2) Right-click somewhere in the settings display (below the Filter
   box), and choose New : String.

3) Enter general.useragent.override as the preference name.

4) Enter the following (without line breaks) as the string value:

   Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_8; en-us)
     AppleWebKit/531.21.8 (KHTML, like Gecko) Version/4.0.4 Safari/531.21.10

Here's a page that (among other things) displays your browser's
current user agent string:

http://www.gemal.dk/browserspy/basic.html
Here's a debugging patch that

1) hooks and logs the following Text Services Manager calls

   ActivateTSMDocument()
   DeactivateTSMDocument()
   DeleteTSMDocument()
   NewTSMDocument()
   TSMGetActiveDocument()

2) logs a stack trace on each of the above calls

3) logs the sending of keystrokes to plugins.

Numbers 1 and 2 are substantial innovations -- if I say so myself :-)

I don't believe #1 has ever been documented before -- in fact I wasn't
at first sure it even was possible.  And though #2 has been documented
in principle (at http://www.cocoadev.com/index.pl?StackTraces, not by
Apple), there's a potentially crippling "catch 22" that I had to learn
to work around (the Symbolication framework can take a minute to
initialize when used with Firefox).

Here's a tryserver build made with my patch:
https://build.mozilla.org/tryserver-builds/smichaud@pobox.com-bugzilla520312-debug/bugzilla520312-debug-macosx.dmg

With my patch (and tryserver build), you can see a couple of the
things Silverlight does differently when it thinks its running in
Firefox or Safari:  Only in "Firefox-mode" does Silverlight call
TSMGetActiveDocument() and DeactivateTSMDocument() (from
BitmapSource_SetSource in Contents/MacOS/agcore) when processing text
input while doing IME.

From #3 above, you can also see that Firefox sends exactly the same
keystrokes to Silverlight in "Firefox-mode" and "Safari-mode".
INCOMPLETE due to lack of activity since the end of 2009.

If someone is willing to investigate the issues raised in this bug to determine whether they still exist, *and* work with the site in question to fix any existing issues, please feel free to re-open and assign to yourself.

Sorry for the bugspam; filter on "NO MORE PRE-2010 TE BUGS" to remove.
Status: REOPENED → RESOLVED
Closed: 10 years ago9 years ago
Resolution: --- → INCOMPLETE
Product: Tech Evangelism → Tech Evangelism Graveyard
You need to log in before you can comment on or make changes to this bug.