Closed Bug 315972 Opened 19 years ago Closed 10 years ago

East-Asian input methods, keyboard unresponsivity, java applets

Categories

(Core Graveyard :: Plug-ins, defect)

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

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME

People

(Reporter: phiw2, Unassigned)

Details

(Keywords: intl)

Attachments

(5 files, 2 obsolete files)

Apple crash log
36.66 KB, text/plain
Details
Java applets with Unicode text
4.91 KB, application/zip
Details
English language version of jlearn applet
2.53 KB, application/zip
Details
Chinese language version of jlearn applet
2.55 KB, application/zip
Details
result of inputting 'katakana' with Japanese input
11.75 KB, image/png
Details 
User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20051110 Firefox/1.6a1
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20051110 Firefox/1.6a1

Follow-up on bug 313807.

When the user has one of the east-Asian input methods active, the keyboard becomes mostly unresponsive when a page containing java applets is loaded.
* Fayt doesn't launch
* spacebar doesn't scroll the page,
* cannot input anything in form input fields and textareas
* some other keyboard shortcuts are randomly unresponsive (command-1, 2, 3 to switch tabs).
This propagates to all open tabs.

Restart of the browser, or opening a new window restores the interaction between the keyboard and the browser window.

Reproducible: Always




OS X 10.3.9
I'm testing this on a stock 15" Powerbook as sold in Japan with the 'Apple Shift-Jis' keyboard. The problem also happens with Apple' extended keyboards as sold in Japan.

Tested with JEP 0.9.5+b, part of the browser install, see bug 315637.
Version: unspecified → Trunk
> Fayt doesn't launch

What is "fayt"?

(In reply to comment #1)
> > Fayt doesn't launch
> 
> What is "fayt"?
> 

"Find as you type"
Then I'm not sure what you mean by "it doesn't launch".

Is there any place at all where you _can_ enter text (any text at all)?

If you open a new window, does that have the same problem?  Or does the
problem only start happening when you load an applet in that window, too?

Can you change your keyboard layout to something else than shift_jis?  If so,
does that make the problem go away?

(On my own computer, which is a dual-1Ghz CPU G4 PowerPC desktop sold in the
US, I have no problems with any of the Chinese or Japanese input methods.  But
then again none of my keyboard layouts uses shift_jis.)


> If you open a new window, does that have the same problem?

I see that you've already answered this question:

> Restart of the browser, or opening a new window restores the interaction
> between the keyboard and the browser window.


(In reply to comment #3)

(In reply to comment #3)
> Then I'm not sure what you mean by "it doesn't launch".

On a page that contains an applet, the applet loads, then I can try all I want to trigger FAYT by typing '/' and nothing happens. The computer beeps at me.

> Is there any place at all where you _can_ enter text (any text at all)?
Nowhere at all. Not in the document area, not in the chrome area (search box, url field), not in any form input field (textarea, etc).
If I switch keyboard layout to US, or US extended, then yes, I can type away. But then I'm unable to input any Japanese text.
> 
> If you open a new window, does that have the same problem?  Or does the
> problem only start happening when you load an applet in that window, too?
Opening a new window allows me to type and restores all the keyboard functionality. As soon as I load a page with some java applet, the problem returns.

> Can you change your keyboard layout to something else than shift_jis?  If so,
> does that make the problem go away?
I can switch to another keyboard layout - i.e. US, or French, but only by going to the menu bar, or that little floating palette (input mode palette). The keyboard shortcut (command+spacebar) to cycle thru the two most recently used ones is non functional.

> (On my own computer, which is a dual-1Ghz CPU G4 PowerPC desktop sold in the
> US, I have no problems with any of the Chinese or Japanese input methods. But
> then again none of my keyboard layouts uses shift_jis.)

Are you running 10.4? Would that be a 10.3.x only problem?
I've tested on the kid's iBook, which always runs as a 'Japanese' user (OS language is Japanese, 10.3.9), and the problem is there as well.
> I can switch to another keyboard layout - i.e. US, or French, but only by
> going to the menu bar,

What if you do this before an applet is loaded -- do you then still have
problems after loading an applet?

>> (On my own computer, which is a dual-1Ghz CPU G4 PowerPC desktop sold in the
>> US, I have no problems with any of the Chinese or Japanese input methods.
>
>Are you running 10.4? Would that be a 10.3.x only problem?

No.  I have bootable partitions with 10.2.8, 10.3.9 and 10.4.3.  The Chinese
and Japanese input methods work fine in all of them.

One thing I've never tried, though, is to change my default keyboard layout to
anything other than US English.  I'll try that over the weekend.

An old question put more clearly:

How about if you start with a US or French keyboard, load an applet, then
switch to one of the Japanese input methods (say hiragana or katakana) -- do
they work then?

(In reply to comment #7)
> An old question put more clearly:
> 
> How about if you start with a US or French keyboard, load an applet, then
> switch to one of the Japanese input methods (say hiragana or katakana) -- do
> they work then?

If I have, say, the US keyboard (little us flag in the menu bar) active before accessing the page with an applet, everything works correctly. Switching to Hiragana or Katakana, and it's broken in all tabs.

One thing. The Japanese keyboards have two extra keys around the spacebar to switch between input methods (left of spacebar, switch to 'roman' input; right of space-bar, switch to kanas and kanjis). Now, if I load a page while 'us' is active, then switch to kana input from the *menu bar*, I can still input something in a textarea or input-field on the same (but if I try to open a new tab, it's all broken). However, if I switch using the keyboard, I can't input anything.
(tested on the Java.com test page, which has some input fields
http://www.java.com/en/download/help/testvm.xml)

-----
keyboard looks like this (laptops):

option key | command key | switch to roman | spacebar | switch to kana | fn key 

The average windows keyboard sold here has the same layout, more or less.


At bug 313807 you say that, as of JEP 0.9.5+b, you're only having problems
with trunk builds (not with mozilla-1.8-branch builds):

https://bugzilla.mozilla.org/show_bug.cgi?id=313807#c20

Is this still correct?

> One thing. The Japanese keyboards have two extra keys around the spacebar to
> switch between input methods (left of spacebar, switch to 'roman' input;
> right of space-bar, switch to kanas and kanjis). Now, if I load a page while
> 'us' is active, then switch to kana input from the *menu bar*, I can still
> input something in a textarea or input-field on the same (but if I try to
> open a new tab, it's all broken). However, if I switch using the keyboard, I
> can't input anything.

Is it true that you don't have keyboard input problems (even with trunk builds)
if you never touch either of these two keys?  (That is, if you need to switch
to a different keyboard layout or input method, you only use the "flags"
menu.)

> (From my comment #6)
> One thing I've never tried, though, is to change my default keyboard layout
> to anything other than US English.  I'll try that over the weekend.

I just tried this and had no problems.  I changed the default language to
Japanese, logged out and back again again (which changed all my system menus
to Japanese), then chose the Hiragana input method.  I ran the DeerPark
2005-11-13-05-trunk nightly, loaded a Java applet that accepts text input, and
successfully used the Hiragana input method to enter the Chinese characters
for "Japanese" in one of the applet's text boxes.  Then I clicked in
DeerPark's location bar and once again successfully used the Hiragana input
method to enter the Chinese characters for "Japanese".

(In reply to comment #9)
> At bug 313807 you say that, as of JEP 0.9.5+b, you're only having problems
> with trunk builds (not with mozilla-1.8-branch builds):
> 
> https://bugzilla.mozilla.org/show_bug.cgi?id=313807#c20
> 
> Is this still correct?

Hmm, I'll have to test that again. I'm currently on a low bandwidth connection and no recent branch build archived on my Powerbook. But I'm in doubt now.
 
...
> Is it true that you don't have keyboard input problems (even with trunk builds)
> if you never touch either of these two keys?  (That is, if you need to switch
> to a different keyboard layout or input method, you only use the "flags"
> menu.)

I did some more testing (on the java.com test page, as it has some form inputs). Starting with 'us' loaded. No problems. Switch to hiragana (from the menu bar),  and I can input (Japanese) text in a form inputs. I can still work on other pages as well - as long as I don't use the keyboard switcher (but I don't think a Japanese user would ever do that, going to the little flags).

Second test - and here is the problem - I tried switching by using the command+spacebar shortcut (cycling thru last 2 keyboards). Result: keyboard functionality is lost, using the same keyboard shortcut to revert to 'us' restored the functionality.
Next, having the focus in the textarea at the bottom of the page, with 'us' selected, typed a few (roman) letters and touched the 'switch to roman input' key left of the spacebar: very unexpectedly, this resulted in added spaces (as if I had used the spacebar itself). This should _not_ happen. The behaviour of that key is simple: if input is roman: do nothing, else change to roman input. And I never experienced that problem anywhere.


....
> I just tried this and had no problems.  I changed the default language to
> Japanese, logged out and back again again (which changed all my system menus
> to Japanese), then chose the Hiragana input method.  I ran the DeerPark
> 2005-11-13-05-trunk nightly, loaded a Java applet that accepts text input, and
> successfully used the Hiragana input method to enter the Chinese characters
> for "Japanese" in one of the applet's text boxes.  Then I clicked in
> DeerPark's location bar and once again successfully used the Hiragana input
> method to enter the Chinese characters for "Japanese".

Then the problem is limited to those Japanese keyboards, I guess.
> Second test - and here is the problem - I tried switching by using the
> command+spacebar shortcut (cycling thru last 2 keyboards). Result: keyboard
> functionality is lost, using the same keyboard shortcut to revert to 'us'
> restored the functionality.

Interesting.  I tried this myself and had no trouble.

I'm now wondering if I'd be able to reproduce your problems even on a
Japanese-style keyboard (the kind with the two extra "switch to roman" and
"switch to kana" keys).

I'm afraid that at this point I don't have enough information to do anything
about what you've reported, and am not likely to get enough anytime soon.

I'd be interested in hearing from others who are using the same kind of
keyboard ... particularly if they're able to use it without the same kinds of
problems :-)


I now suspect that some piece of software that's installed on all your
family's computers (those you've had problems with) is what's causing the
problems you see.

It's very difficult to guess which program (or plugin or driver) this might
be.  But here's a check that's reasonably easy to perform:

See if your computer has a /Library/InputManagers/ directory, and if there's
anything in that directory.  If there's anything there, try dragging it out of
this directory to some other directory, then quitting and restarting Firefox.
It'd be interesting to see if this makes your keyboard input problems go away.


(In reply to comment #12)
> I now suspect that some piece of software that's installed on all your
> family's computers (those you've had problems with) is what's causing the
> problems you see.

Quite unlikely. The kids iBook is pretty much a default setup, and he doesn't have administrative rights (if I run tests on that machine, I do it it as another user). Any way, I double-checked for anything, but a search turned out empty.

The only thing that could be suspect is the Kensington Mouse driver. I uninstalled it, restarted the iBook, checked against the java.com test page and the problems persist.

Idem dito on my Powerbook. Unless some Mysql, Python, Perl, PHP stuff (in /usr/local/bin or other similar places) interferes with the java plugin. Not very likely. Besides, I haven't installed anything like this recently, and those problems with Java started as described in bug 313807.
Thanks for checking.

The troublesome piece of software could be a driver or something else at a
similarly low level.  It could even be something that's installed on all Macs
sold in Japan, but not on Macs sold in the US (or elsewhere).  That's why I
particularly want to hear from others who are using Macs sold in Japan.

Are you located in Japan?  Do you know others who'd be willing to test recent
DeerPark nightlies?

(By the way, I assume that you _don't_ have problems with the Firefox 1.5 RCs.
Please check when you have the chance, and tell me whether or not this is
correct.)


> (By the way, I assume that you _don't_ have problems with the Firefox 1.5
> RCs.  Please check when you have the chance, and tell me whether or not this
> is correct.)

Of course, to stop bug 313807 from interfering with your tests, you'll need to
remove these distros' embedded copies of the JEP (JavaEmbeddingPlugin.bundle
and MRJPlugin.plugin in each distro's Contents/MacOS/plugins director) and
install JEP 0.9.5+b to /Library/Internet Plug-Ins.


I can see this problem on Firefox 1.5 RC3 with JEP 0.9.5+b and
20051117-trunk using Apple JIS keyboard and Powerbook sold in Japan.
I will ask Japanese Mac users.
Keywords: intl
(In reply to comment #14)
 
> The troublesome piece of software could be a driver or something else at a
> similarly low level.  It could even be something that's installed on all Macs
> sold in Japan, but not on Macs sold in the US (or elsewhere).  That's why I
> particularly want to hear from others who are using Macs sold in Japan.

Would Apple install some special sofware for those Japanese keyboards ? in /System/Library/Keyboard layouts I have a bunch of .bundle files. Would those be different ? Or some .kext file ? If yes, I can copy them and make them available.
> 
> Are you located in Japan?  Do you know others who'd be willing to test recent
> DeerPark nightlies?

I've emailed someone who knows Firefox quite well.

> 
> (By the way, I assume that you _don't_ have problems with the Firefox 1.5 RCs.
> Please check when you have the chance, and tell me whether or not this is
> correct.)

I've tested this again with Firefox 1.5 (build 2005116), and it breaks just thee same as with trunk builds. On my previous test, I had forgotten that Java was disabled on that machine (I don't use a browser that often on that machine ..).

BTW, with the latest JEP, it works all correctly with Camino, nightly branch build 20051117.
we confirmed this in bugzilla-jp (in Japanese, sorry)
http://bugzilla.mozilla.gr.jp/show_bug.cgi?id=4778

steps to reproduce:
1. launch Mozilla/Firefox.
2. open https://bugzilla.mozilla.org/attachment.cgi?id=201351
3. turn on IME (kotoeri).

if we first open another page with <applet>
(ex. http://www.parkcity.ne.jp/~chaichan/src/jlearn08.htm),
this problem doesn't occur.

I believe this is Core issue, but which component?
bug 92814 depends on this.
Blocks: 92814
(In reply to comment #18)

> we confirmed this in bugzilla-jp (in Japanese, sorry)
> http://bugzilla.mozilla.gr.jp/show_bug.cgi?id=4778

I can read a little Japanese, so I skimmed through the comments at
that bug.  I believe nobody said what kind of computer they're using.
Is it possible that this problem is confined to laptops?  Have you
tested on a Mac desktop sold in Japan?

I also noticed that, though OS X 10.4.3 and 10.3.9 were mentioned,
nobody claims to have tested on OS X 10.2.8.  I'd be interested to
hear from somebody who's tested on a Mac sold in Japan running OS X
10.2.8.  It's possible that the earlier OS version doesn't have the
troublesome driver(s) that may be causing this problem.

> 3. turn on IME (kotoeri).

Does it make any difference if you use the "flags" menu to turn on one
of the Kotoeri input methods, instead of Command+spacebar or the
"switch to kana" key?

> if we first open another page with <applet>
> (ex. http://www.parkcity.ne.jp/~chaichan/src/jlearn08.htm),
> this problem doesn't occur.

Very interesting ... and also very puzzling.

Will any applet do?  The example you give displays Japanese text,
which may make a difference.  What if you load an applet that only
displays Roman characters?

Does it have to be another page?  In other words, if you first open
the parkcity applet and then (in the same page) open attachment
201351, do the problems go away?

> I believe this is Core issue, but which component?

My working assumption is that some driver or other low-level software
(which is unique to Macs sold in Japan) disables or interferes with
the Cocoa-Carbon interface that the Java Embedding Plugin uses when
it's run from Carbon browsers (like Firefox, Seamonkey and the Mozilla
Suite).  This would explain why the problems don't happen when the JEP
is used with Camino (which is a Cocoa browser), or when Firefox is
used with Java 1.3.1 (which uses Carbon, in contrast to Java 1.4.X and
5.0 which use Cocoa).

> bug 92814 depends on this.

I doubt it.  Bug 92814 is very old, and is probably completely
unrelated.
(In reply to comment #17)

> I've tested this again with Firefox 1.5 (build 2005116), and it breaks just
> thee same as with trunk builds. On my previous test, I had forgotten that
> Java was disabled on that machine (I don't use a browser that often on that
> machine ..).

Bad news ... but it makes better sense this way.  Thanks for checking.

> BTW, with the latest JEP, it works all correctly with Camino, nightly branch
> build 20051117.

Thanks for letting me know.

As I said in my previous comment (comment #19), I think the trouble is caused
by a driver (or some other low-level software) disabling or interfering with
the Cocoa-Carbon interface that the Java Embedding Plugin uses when run from
Firefox (which is a Carbon browser).

So I'm not surprised that Camino-with-the-JEP doesn't have this problem -- it
tends to confirm my working theory.

> Would Apple install some special sofware for those Japanese keyboards?

Very likely they would -- though the driver may be present on every OS X CD
and only installed on computers sold in Japan.  After all, the Japanese
keyboard is physically different from the keyboard Apple uses in the US (and I
think in the rest of the world).

> in /System/Library/Keyboard layouts I have a bunch of .bundle files. Would
> those be different ? Or some .kext file ? If yes, I can copy them and make
> them available.

Here's a list of the bundles I have in my /System/Library/Keyboard Layouts/
directory (on OS X 10.3.9, for comparability with your system):

  drwxr-xr-x   30 Apr  2004 CentralEuropean.bundle
  drwxr-xr-x   30 Apr  2004 Cyrillic.bundle
  drwxr-xr-x   30 Apr  2004 Dvorak.bundle
  drwxr-xr-x   30 Apr  2004 Japanese.bundle
  drwxr-xr-x   30 Apr  2004 Korean.bundle
  drwxr-xr-x   30 Apr  2004 Roman.bundle
  drwxr-xr-x   30 Apr  2004 SimplifiedChinese.bundle
  drwxr-xr-x   30 Apr  2004 TraditionalChinese.bundle
  drwxr-xr-x   30 Apr  2004 Unicode.bundle

But I think the problem's more likely to be elsewhere.  "kextstat" is a
program that you can use (in a Terminal session) to list all the "kernel
extensions" that are currently loaded.  On my system (which is a dual-1Ghz-CPU
G4 PowerPC desktop) no keyboard-specific drivers are listed at all.  When I do
"kextstat | grep -i key" (which does a case-insensitive search to find all the
kernel extensions whose names include the string "key"), I get the following:

  com.apple.iokit.IOKeyLargo (1.5.6d0) <10>
  com.apple.driver.AppleKeyLargo (1.5.6d0) <26 16 15 10>
  com.apple.driver.KeyLargoATA (1.1.0f1) <32>

But "KeyLargo" has nothing (specifically) to do with keyboards -- it's a
low-level IO controller:

http://developer.apple.com/documentation/Hardware/Developer_Notes/Macintosh_CPUs-G4/PowerMacG4/2Arc\
hitecture/chapter_3_section_6.html

I'd be interested to see the results of "kextstat | grep -i key" on your
system (excluding all the matches for "KeyLargo").
Status: UNCONFIRMED → NEW
Ever confirmed: true
(In reply to comment #19)
>  Have you tested on a Mac desktop sold in Japan?

I have tested with a desktop G4 with the stock keyboard as sold in Japan. Same problem(s).

(In reply to comment #20)

On my Powerbook (1.5 Ghz, October 1004)
[/System/Library/Keyboard Layouts] $ ls -al

drwxr-xr-x   3 root  wheel   102 28 Jan  2004 CentralEuropean.bundle
drwxr-xr-x   3 root  wheel   102 28 Jan  2004 Cyrillic.bundle
drwxr-xr-x   3 root  wheel   102 28 Jan  2004 Dvorak.bundle
drwxr-xr-x   3 root  wheel   102 28 Jan  2004 Japanese.bundle
drwxr-xr-x   3 root  wheel   102 28 Jan  2004 Korean.bundle
drwxr-xr-x   3 root  wheel   102 28 Jan  2004 Roman.bundle
drwxr-xr-x   3 root  wheel   102 28 Jan  2004 SimplifiedChinese.bundle
drwxr-xr-x   3 root  wheel   102 28 Jan  2004 TraditionalChinese.bundle
drwxr-xr-x   3 root  wheel   102 28 Jan  2004 Unicode.bundle

The desktop G4 returns the same, except for the date (1 jan 2004, the day I installed 10.3 on that machine).

kextstat | grep -i key

   26    1 0x99d000   0x6000     0x5000     com.apple.iokit.IOKeyLargo (1.5.6d0) <10>
   27    0 0x9a3000   0x7000     0x6000     com.apple.driver.AppleKeyLargo (1.5.6d0) <26 16 15 10>
   43    0 0xadb000   0x3000     0x2000     com.apple.driver.KeyLargoATA (1.1.0f1) <28>
   58    0 0x920000   0x4000     0x3000     com.apple.driver.AppleADBKeyboard (2.3.7f3) <41 18 10>

The desktop G4 returns the same, minus the com.apple.driver.AppleADBKeyboard.
From discussions about the 'SideTrack' [1] utility, I recall this is the driver for the laptop keyboards. Note that Sidetrack is not the reason of the problems, it is not installed on the iBook I mentioned previously.

[1] http://www.ragingmenace.com/software/sidetrack/index.html
I tested the http://www.parkcity.ne.jp/~chaichan/src/jlearn08.htm page, then loaded the java.com test page (same tab and in a new tab), and indeed, I did not have any problems. Opened up other pages with form input fields (same tab, other tab), and again, no problems with keyboard input.
All this working from the keyboard only.

Do you have a link to a similar applet, but with Roman characters ?

ps - In comment 21, the Powerbook is from Oct 2004, not 1004 ..;-)
> Do you have a link to a similar applet, but with Roman characters?

Here are a couple of Sun's demo applets.  Both applets display at least some
Roman script.  The first (Clock) has no fields for character input.  But the
second (ArcTest) does.  So it would be possible to enter kana or kanji in
ArcTest's input fields.

http://java.sun.com/applets/jdk/1.4/demo/applets/Clock/example1.html
http://java.sun.com/applets/jdk/1.4/demo/applets/ArcTest/example1.html


Loading the 'clock' sample, and same problems as described before.
While I was there, I tried to put focus on the location bar (command -L). That worked, but I was completely unable to type anything in the location field.

At the Arctest sample, I could type in the fields, probably because those are within the applet. But I had to use the mouse to put the focus. But no much keyboard functionility out side of the applet. triggering a keyboard shortcut, mostly yes (command + key). Typing: no. Fayt is the do or break thing.

The Japanese teaching applet from comment #18; I suspect it somehow 'works' because it kidnaps the focus.  When the applet loads, the input field has focus (focus ring around the field, start typing goes into the field. But I can't trigger fayt, nor typing in the location bar.

At one point the browser crashed when attempting to paste a url in the location bar; Talkback TB12048291M.

Thanks for your tests.  But please try loading the ArcTest applet, entering
kana in one of its text boxes, and then trying to enter text in the location
bar.

> At one point the browser crashed when attempting to paste a url in the
> location bar; Talkback TB12048291M.

Talkback doesn't give enough information.  Please attach the OS X crash log
for this crash (i.e. use "create a new attachment").  The log should be in
~/Library/Logs/CrashReporter/firefox-bin.crash.log, towards the end of the
file.  Use Talkback's timestamp and stack trace to find the correct crash log
in firefox-bin.crash.log.
Status: NEW → ASSIGNED
Assignee: nobody → smichaud
Status: ASSIGNED → NEW
Status: NEW → ASSIGNED
Attachment #203742 - Attachment is obsolete: true
Attachment #203741 - Attachment is obsolete: true
Comment on attachment 203742 [details]
Applet with Japanese Unicode text

<HTML><HEAD><TITLE>Japanese Unicode Label</TITLE>

<BASE href="https://bugzilla.mozilla.org/attachment.cgi?id=203741"/></HEAD>
<BODY>
<APPLET width="150" height="50" code="JapaneseUnicodeLabel" archive="JapaneseUnicodeLabel.jar">
Your browser does not support Java, so nothing is displayed.
</APPLET>
</BODY></HTML>
(In reply to comment #25)
> Thanks for your tests.  But please try loading the ArcTest applet, entering
> kana in one of its text boxes, and then trying to enter text in the location
> bar.

Doesn't work, the location bar I mean. Typing in any language works fine.
Note: in the previous test, I had first loaded the Clock applet. When loading the  Arctest one, there was no focus on the input fields in the applet (manually setting it with a mouse click required). I now loaded the Arctest as first thing, and this time the focus was on the left most input field.
Attached file Apple crash log — 
per comment #25
> Apple crash log

It's more informative than the Talkback log, but it's still puzzing:  The
crash appears to happen in OS code (in com.apple.AE, which I'd guess is the
AppleEvent engine), but java_vfprintf is (I think) in
JavaEmbeddingPlugin.bundle (in Handlers.m).

My hunch is that the crash log is partially corrupt.  Let's put it aside for
the time being.  It's probably an unrelated problem anyway.


I decompiled the jlearn applet (from
http://www.parkcity.ne.jp/~chaichan/src/jlearn08.htm) and found that
its Japanese text uses Unicode encoding.  On the chance that this is
significant, I made three simple test applets, each of which contains
Unicode text in a different language.

Please download and expand my zip file, then for each html file that
it contains please do the following:

1) Quit and restart Firefox.
2) Choose File : Open from inside Firefox and open one of the html
   files -- the corresponding applet should be loaded.
3) See whether or not you're able to use the keyboard to input text in
   Firefox's text fields (like the location bar) in the same window.


I've since found the source for the jlearn applet online:

http://www.parkcity.ne.jp/~chaichan/src/java09.htm

Thank you for the testcases.
Tested using Firefox 20051120-trunk on OS 10.3.9, Japanese language,
desktop G4 sold in Japan.
# Firefox crashed several times in testing probably for another reason.

First test - ChineseUnicodeLabel and EnglishUnicodeLabel caused
the problem, JapaneseUnicodeLabel didn't.
Second test - all 3 files caused the problem...
I'm not sure what happens...
This may be related to initial focus issue described in comment 24.

> > I believe this is Core issue, but which component?

What I meant was this is not only Firefox, so this should be moved to
Core Product in Bugzilla.
Reproduced with SeaMonkey.  Moving to Core/Plug-ins for the moment
since removing JEP solves this.

> I doubt it.  Bug 92814 is very old, and is probably completely
> unrelated.

Yes, sorry for confusing too.  I meant to say that using JEP solves
Bug 92814, but this is troublesome for Japanese.  Removing dependency.
No longer blocks: 92814
Component: Keyboard Navigation → Plug-ins
Product: Firefox → Core
(In reply to comment #32)

> 3) See whether or not you're able to use the keyboard to input text in
>    Firefox's text fields (like the location bar) in the same window.
> 

In all 3 cases: I was unable to type anything in the location bar after setting the focus from the keyboard.
In all 3 cases: once the page is loaded, I typed a letter, this should normally trigger FAYT, but not in this case.
Only with Japanese page:  command L to set the focus in the location bar, I was able to paste - command V - a text string (or a url).

No crashes on my side.
Restart between each of the tests, with clean cache (Tools > Clear Private Data)

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20051120 Firefox/1.6a1 ID:2005112004
OK, it seems that the fact that the jlearn applet displays Japanese text has
nothing to do with its ability to fix this problem.

(I assume that people's tests on Macs sold in Japan still show that loading
the URL http://www.parkcity.ne.jp/~chaichan/src/jlearn08.htm does fix this
problem.)

I'll be out of town (and away from my computer) for most of this week.  But
when I get back I'll make up more test cases from the source code of the
jlearn applet.  My intention is (of course) to find out which part of it fixes
the problem.


Here's an English language version of the jlearn08 applet at
http://www.parkcity.ne.jp/~chaichan/src/jlearn08.htm.  Please try it out and
let me know your results.

I want to know (of course) if an English language version of this applet still
makes this problem (bug 315972) go away.
(In reply to comment #38)
> I want to know (of course) if an English language version of this applet still
> makes this problem (bug 315972) go away.
> 

Tested with
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20051213 Firefox/1.6a1 ID:2005121305
under both 10.3.9 and 10.4

I'm afraid the news isn't too good. I loaded the .html pages from my localhost dev server, then loaded another page (bbc.co.uk) in the same tab. In each case, I lost keyboard functionality as described previously. Restart between each test, clean (new) profile, empty cache.

Something else I noticed now under 10.4.3, up to date. Attempting to type something in those applets, a string of Japanese characters, like 'katakana', gave very weird results: the first character (ka) was correct, the subsequent characters were 'broken', output for 'ta': t (roman t) followed by the kana for 'a', repeated for the subsequent characters. 

In Safari, it was even worse: no output, that is, until I did something with the keyboard (like hiding the app, command H). The output would have the same problems as in Firefox.

10.4 tests on both an 'updated' machine (PowerBook) and a new iMac. The same problems with the Japanese page (mentioned previously).


> I'm afraid the news isn't too good. I loaded the .html pages from my
> localhost dev server, then loaded another page (bbc.co.uk) in the same
> tab. In each case, I lost keyboard functionality as described
> previously. Restart between each test, clean (new) profile, empty cache.

This was with the English language version of the jlearn applet.  Did you try
the Chinese language one, too?  Do these problems still go away after you've
loaded the (original) Japanese language version of this applet at
http://www.parkcity.ne.jp/~chaichan/src/jlearn08.htm?

> Something else I noticed now under 10.4.3, up to date. Attempting to type
> something in those applets, a string of Japanese characters, like
> 'katakana', gave very weird results: the first character (ka) was correct,
> the subsequent characters were 'broken', output for 'ta': t (roman t)
> followed by the kana for 'a', repeated for the subsequent characters.
>
> In Safari, it was even worse: no output, that is, until I did something with
> the keyboard (like hiding the app, command H). The output would have the
> same problems as in Firefox.

This sounds like a different problem, possibly unrelated.  (Whatever problems
you have with Safari have (of course) nothing to do with the Java Embedding
Plugin or Firefox (or Seamonkey).  Though they may indicate a problem with
Apple's JVM.)

Does this (new and different) problem happen with all three language versions
of the jlearn applet (the original Japanese, the English language copy and the
Chinese language copy)?  In both Firesox and Safari?

> The same problems with the Japanese page (mentioned previously).

I don't know what you're referring to here.


(In reply to comment #41)

> This was with the English language version of the jlearn applet.  Did you try
> the Chinese language one, too?  Do these problems still go away after you've
> loaded the (original) Japanese language version of this applet at
> http://www.parkcity.ne.jp/~chaichan/src/jlearn08.htm?

I tested both the English and the Chinese one (as I said: "... loaded the .html pages").
problem doesn't go away unless I open a new window or restart the browser.
> 

> 
> This sounds like a different problem, possibly unrelated.  (Whatever problems
> you have with Safari have (of course) nothing to do with the Java Embedding
> Plugin or Firefox (or Seamonkey).  Though they may indicate a problem with
> Apple's JVM.)
> 
> Does this (new and different) problem happen with all three language versions
> of the jlearn applet (the original Japanese, the English language copy and the
> Chinese language copy)?  In both Firesox and Safari?

As I said, it happens in all 3 applets, both in Firefox and Safari.
The input problems I experienced in Safari are identical to those in Firefox, except that Safari is actually worse (delayed reaction on input within the applet). I'll attach a screenshot.
(to be clear: inputs refers to typing some Japanese characters in the textarea of the applet). And again, that is a 10.4.3 problem (2 computers). It doesn't happen on 10.3.9.

> > The same problems with the Japanese page (mentioned previously).
> 
> I don't know what you're referring to here.
> 
The Japanese jlearn applet.
I inputted the same string twice, separated by a Japanese space
Thanks for clarifying.

> Do these problems [the ones originally reported here, at bug 315972] still
> go away after you've loaded the (original) Japanese language version of this
> applet at http://www.parkcity.ne.jp/~chaichan/src/jlearn08.htm?

But I particularly want to be sure about the answer to this question.


Tested with Firefox 20051213-trunk on OS 10.3.9.

It seems to me I found "the difference" in previous test.
The results depend on whether we open the htmls by "drag & drop" or
"open file/location".

* Previous ChineseUnicodeLabel, EnglishUnicodeLabel, JapaneseUnicodeLabel:

If I open them by "open file" or via local web server, first shortcut key
(ex. cmd+K) doesn't work.  But once I click in the window, cmd+K becomes
to work.  I can type in search bar using IME.
If I open them by drag & drop, I can't type anything while I turn on IME
(and sometimes crashes).

* Original jlearn08, jlearnChinese, jlearnEnglish:

If I open them by "open file" or via local web server, text field in
applet has focus and I can type there.  cmd+K doesn't work when my cursol
is in the field.  Once I click outside the applet, cmd+K becomes to work.
I can type in search bar even if using IME.

If I open them by drag & drop, focus is not in anywhere.  When I put
cursol in the text field in applet by mouse, I can type there, but I
can't type anything in search bar even if putting cursol there by mouse
and trying US mode (and sometimes crashes).

* attachment 201351 [details]:

cmd+K works but I can't type anything while I turn on IME.
If I load jlearn08 or the variations above (and click in the window once),
the problem goes away.
> If I load jlearn08 or the variations above (and click in the window once),
> the problem goes away.

If I load jlearn08 or the variations above (and click in the window once)
via http, the problem goes away.
(In reply to comment #45 and comment #46)

Thanks for your detailed and precise report.  You seem to have found important
additional clues ... but I'm still not able to reproduce any of what you
report (i.e. any of the problems).

I'm beginning to wonder if Japanese keyboards (i.e. Apple's drivers for them)
send special Carbon events.  I've poked holes in Apple's Cocoa-Carbon
interface to allow through specific Carbon events (having to do with mouse and
keyboard input).  But if there are special events that I don't know about, and
which I'm not specifically allowing through, their absence (or their
inconsistent presence) might explain some of these problems.

If you know anything about this, please let me know.  In any case I'll start
looking on the web for whatever information I might be able to find.


One more thing:  The browser's Command+key combinations don't work (in Firefox
and Seamonkey) when the keyboard focus is in a Java applet.  This is
mozilla.org's design decision, and I think it's a bit unfortunate.  Even
Camino doesn't behave this way.  But only mozilla.org can change this.


I'm not going to be able to fix this bug until I get an Apple Japanese
Shift-JIS keyboard.  (I may not be able to fix it even then, but at
least I will have learned more about the nature of this problem.)

Does anyone have any advice about how I can get one?

(I tried ordering one online from Apple's Japan branch of their Apple
Store, but their checkout wouldn't accept an address outside of Japan
-- the address fields were Japan-specific, and the site refused to
accept US-specific information in those fields.  I will send email to
Apple's US Apple Store asking for their help ... but if anyone here
has tried making an international order from Apple Store Japan, I'd
appreciate knowing how you did it.  My Japanese isn't up to writing in
Japanese to Apple Store Japan.)


I've now confirmed that the Apple Store in Japan won't ship abroad,
and that it's impossible to get the Apple JIS Keyboard (M9034J/A) from
the US Apple Store.  I tried ordering one from amazon.co.jp ... but
they don't offer this keyboard directly (only via "partners"), and the
partners are unwilling to ship abroad.

My Japanese is too limited to carry my research much further, so I'd
really appreciate it if someone could suggest some online stores in
Japan that 1) carry the M9034J/A keyboard and 2) are willing to ship
it abroad.


Nakano-san,

Can the problem of comment#49/comment#50 be helped with Mozilla-japan?
QA Contact: keyboard.navigation → plugins
I've just released a new version (0.9.6) of the Java Embedding Plugin.
There's about a 50% chance that it may have resolved this problem.
See bug 364158.

I still don't have an Apple JIS keyboard, so my changes don't (of
course) target this bug directly.  But I've been able to figure out
how to avoid using Apple's buggy keyboard and mouse Carbon event
handlers with Carbon-based browsers (like Firefox and Seamonkey), and
doing this has resolved many other problems.  (I cover this topic in
item #5 of JEP 0.9.6's change log.)

Please let me know your results.

(In reply to comment #52)

> Please let me know your results.
>
Steven,

Minefield latest, with JEP 0.9.6 [1]
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20061217 Minefield/3.0a1 ID:2006121719 [cairo] 

Good. I went to the Sun test page (linked from about plugins), and didn't find any problems.
Also went to the test pages you linked to in comment 23.
Switching between IME and Roman input, triggering FAYT, keyboard shortcuts, any of the problems mentioned above seem to work correctly.

The only problem I found: not able to switch tabs from the keyboard (command-option [ or ]) after a page with Java Applet loaded. Could be unrelated.

I'll test later with the latest Bon Echo (FX 2.0) build.


[1] I replaced the existing 0.9.5+g+2 with the new 0.9.6 in Minefield>Contents>MacOS>plugins


(In reply to comment #52)
> I've just released a new version (0.9.6) of the Java Embedding Plugin.
> Please let me know your results.
> 

There is no problem in Japanese input. 

Test Page:
http://www1.parkcity.ne.jp/chaichan/src/jlearn08.htm

Mac OS X 10.3.9
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20061217 Minefield/3.0a1
I'm very glad to hear that JEP 0.9.6 seems to have resolved this
problem.  That's a stroke of good luck!

> The only problem I found: not able to switch tabs from the keyboard
> (command-option [ or ]) after a page with Java Applet loaded. Could
> be unrelated.

I can't get command-option [ or ] to change tabs even before any Java
applets are loaded (in a recent Minefield, 2006-12-09-04-trunk).  Is
this something that only works with an Apple JIS keyboard?

(In reply to comment #55)
> I can't get command-option [ or ] to change tabs even before any Java
> applets are loaded (in a recent Minefield, 2006-12-09-04-trunk).  Is
> this something that only works with an Apple JIS keyboard?
> 

Not command-option [ or ].
The keyboard shot cutting is Cmd+Opt+Right Arrow or Cmd+Opt+Left Arrow. 
(See help)
And this short cut doesn't work when there is focus in the applet. 

In addition, Cmd+v(Past) doesn't work in the following applets. 
It works in Safari. 
And this works when Past is chosen from the context menu. 
http://www1.parkcity.ne.jp/chaichan/src/jlearn08.htm

> Not command-option [ or ].
> The keyboard shot cutting is Cmd+Opt+Right Arrow or Cmd+Opt+Left Arrow.
> (See help)

You said "command-option [ or ])" in your comment #53 ... but no
matter.

> And this short cut doesn't work when there is focus in the applet.

I'm able to reproduce this in a couple of recent Minefield nightlies
and in Firefox 2.0.  It's unrelated.  And I'm not sure what (if
anything) I'll be able to do about it -- it's this kind of problem
that tends to be cleared up by my no longer using Apple's buggy
keyboard and mouse event handlers.  If you really care about this,
please open a new bug.

> In addition, Cmd+v(Past) doesn't work in the following applets.
> It works in Safari.
> And this works when Past is chosen from the context menu.
> http://www1.parkcity.ne.jp/chaichan/src/jlearn08.htm

This is a bug in recent Minefield nightlies.  I was able to reproduce
it with 2006-12-09-04-trunk, but not with 2006-11-04-trunk.  (In both
cases I used JEP 0.9.6.)
(Following up comment #55)

This bug may not be resolved after all (at least in Carbon-based
browsers).

All those who reported it were using Carbon-based browsers (as
Minefield was when this bug was first reported).  But (I suspect) this
problem never occurred with Cocoa-based browsers (e.g. Camino).  And a
few months ago Minefield switched to using Cocoa widgets -- so it's
now Cocoa-based, too.

So please test the following, and let me know your results:

1. Camino 1.0.3
  a. With its bundled JEP 0.9.5+g
  b. With JEP 0.9.6

2. Firefox 2.0
  a. With its bundled JEP 0.9.5+g+2
  b, With JEP 0.9.6

3. Recent Minefield dated 2006-12-17 or earlier
  a. With its bundled JEP 0.9.5+g+2
  b. With JEP 0.9.6

(Firefox 2.0 is still Carbon-based.)

(Following up comment #57)

>> And this short cut doesn't work when there is focus in the applet.
>
> I'm able to reproduce this in a couple of recent Minefield nightlies
> and in Firefox 2.0.  It's unrelated.  And I'm not sure what (if
> anything) I'll be able to do about it -- it's this kind of problem
> that tends to be cleared up by my no longer using Apple's buggy
> keyboard and mouse event handlers.  If you really care about this,
> please open a new bug.

I can't reproduce this problem in Camino 1.0.3 or 1.1a1, using either
JEP 0.9.5+g or JEP 0.9.6.  So this problem happens in some Cocoa-based
browsers (the Minefield nightlies) but not in others (Camino).  And it
also happens in a Cocoa-based browser (Firefox 2.0).  I suspect the
cause is some kind of Mozilla.org bug.  If you're interested, please
open a new bug.  At some point (not too soon) I will look into it
further, and try to figure out where the Mozilla.org bug is.

(My stop-using-Apple's-event-handlers fix addresses Carbon-based
browsers, but has no effect on Cocoa-based ones.)

> And it also happens in a Cocoa-based browser (Firefox 2.0).

This should be "And it also happens in a Carbon-based browser (Firefox
2.0)".

Groan.  Sorry!

> (My stop-using-Apple's-event-handlers fix addresses Carbon-based
> browsers, but has no effect on Cocoa-based ones.)

I should have been clearer:  Apple's buggy mouse and keyboard
Carbon-event handlers (for their Cocoa-Carbon interface) aren't
installed or used with Cocoa-based browsers.  So they're not there to
cause any problems.
No longer depends on: 364158
Assignee: smichaud → nobody
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → WORKSFORME
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: