Closed Bug 313807 Opened 18 years ago Closed 18 years ago

Mac: Unicode keyboard layouts stop working after visiting a page with <applet> tag

Categories

(Core Graveyard :: GFX: Mac, defect)

Product:
Core Graveyard
Component:
GFX: Mac
Platform:
PowerPC
macOS
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
mozilla1.8.1

People

(Reporter: uriber, Assigned: jaas)

References

(
URL
)

Details

(4 keywords, Whiteboard: relnote?)

Attachments

(1 file)

minimal testcase
102 bytes, text/html
Details 
Occasionally, I try switching to a non-US keyboard layout (usually Hebrew), only to discover that Firefox doesn't seem to see any of my keystrokes. At this state, when the active keyboard layout is anything other than "US", Firefox ignores most keypresses (including, e.g. the spacebar, but not including the return and backspace keys). Actually, they keypresses aren't completely ignored: the pointer does disappear as it should, but nothing is typed into the text control the caret is in (either inside the page, or in the URL bar, search bar, etc.). Command-letter combinations also don't work.

At the same time, other applications (including other instances of Firefox) work correctly with the selected keyboard.
The only workaround I found is to restart the browser (opening a new browser window doesn't help).

This is something which has been happening to me for the last couple of months, about twice a week. It always happens in branch nightlies - but that's likely because those are the builds I use for everyday browsing.

I have no steps to reproduce. It's also likely that I'm noticing the problem much after it actually started, because I only occasionally use a non-US layout.

The fact that it only ever happens to me in Firefox makes me think that this is, in fact, a Mozilla/Firefox bug, and not just some glitch on my machine. I'm submitting this report (as UNCONFIRMED) in hope that someone would be able to help me come up with an idea of what might trigger this, or how to analyze the problem when it does happen.
In this state, double-clicking a character in the "Character Palette" tool also doesn't work as an input to Firefox. Dragging a character from the Character palette does work.
I don't know if this tid-bits will help with your quest:

There have been more bug reports in the past about loss of keyboard funtionality with non-us keyboard layouts: bug 280805, or some keyboard shortcuts not working correctly (bug 273208, which affects me daily); these are only a few of them that I have bookmarked.

Recently, I've had more frequently problems with the spacebar suddenly not scrolling a page anymore (happens very randomly, I haven't found any pattern to file a bug yet; it seems more frequent when launching a url from an other application). Today, FAYT was gone suddenly, a restart brought it back [1].

This happens with the default keyboard layout for my Powerbook, which is shift_jis.

[1] with todays build Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20051026 Firefox/1.6a1 ID:2005102604
Also bug 299514 for loss of functionality. The symptoms in that bug are mostly
gone on _my_ side, althought the copy/paste problem sometimes happen (again,
randomly, which makes it very difficult to track).
Hah! I founds steps to reproduce:
1. Go to http://www.labait.co.il/mador_item.asp?mador=fixing&id=31
2. All keyboard layouts other than U.S. stop working.

I can reproduce this with recent trunk builds of both Firefox and SeaMonkey, but not with Firefox 1.0. I'll work on a minimal testcase and regression window.
Assignee: nobody → joshmoz
URL: http://www.labait.co.il/mador_item.as...
Status: UNCONFIRMED → NEW
Component: General → GFX: Mac
Ever confirmed: true
Keywords: regression
Product: Firefox → Core
QA Contact: general → mac
Regression range on the 1.8 branch is between 2005-08-17-08 and 2005-08-18-06.
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=MOZILLA_1_8_BRANCH&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2005-08-17+07%3A00&maxdate=2005-08-18+07%3A00&cvsroot=%2Fcvsroot

Regression range on trunk is between 2005-08-17 and 2005-08-19 (can't find a 2005-08-18 build), so, assuming this wasn't broken on the branch before being broken on the trunk, it's the same range as branch.
Flags: blocking1.8rc2?
This actually happens after visiting any page with an <applet> tag (even if the "code" attribute points to a non-existing file).
I'll attach a minimal testcase shortly.
Keywords: testcase
Summary: Mac: Non-default keyboard layouts occasionally stop working → Mac: Non-default keyboard layouts stop working after visiting a page with <applet> tag
Attached file minimal testcase — 
All this contains is: <applet code="foobar"></applet> (inside the <body> element).
So, this was probably caused by bug 303161.
Blocks: 303161
I've partially confirmed your report, and am pretty sure that what I've seen
is a problem with the Java Embedding Plugin (I'm the program's author).

But I'm going to be out of town for the next week, and won't be able to do
more than a cursory initial report until after I get back.

I did my tests on Mac OS X 10.3.9 using Firefox 1.0.7 plus the latest version
(0.9.5+a) of the Java Embedding Plugin (http://javaplugin.sourceforge.net/).
The reason I tested with Firefox 1.0.7 is to rule out other factors that may
be limited to the more recent Firefox builds.

Non-US keyboards that use Roman script seem to work fine.  Even the Russian
keyboard works ... but (oddly) not the Greek one.  Input methods for Chinese
and Japanese also work fine.  But Hebrew and Arabic and Thai keyboards don't
work.  So it's not just the right-to-left keyboards that don't work.

> In this state, double-clicking a character in the "Character Palette" tool
> also doesn't work as an input to Firefox. Dragging a character from the
> Character palette does work.

I've confirmed this, too.

> This happens with the default keyboard layout for my Powerbook, which is
> shift_jis.

Odd.  Do you have problems with any of the Japanese input methods?


(In reply to comment #9)
> Non-US keyboards that use Roman script seem to work fine.  Even the Russian
> keyboard works ... but (oddly) not the Greek one.  Input methods for Chinese
> and Japanese also work fine.  But Hebrew and Arabic and Thai keyboards don't
> work.  So it's not just the right-to-left keyboards that don't work.

It seems that all keyboard layouts using the "Unicode" script are affected, while all others aren't. (You can see what script is associated with each layout in the "International" control panel, under the "Input Menu" tab). E.g., Greek is Unicode (thus affected), but Russian is Cyrillic (and thus not affected).

> > This happens with the default keyboard layout for my Powerbook, which is
> > shift_jis.
> 
> Odd.  Do you have problems with any of the Japanese input methods?

Please notice that the comment you quoted above was not from me, and is probably describing an unrelated issue.
Summary: Mac: Non-default keyboard layouts stop working after visiting a page with <applet> tag → Mac: Unicode keyboard layouts stop working after visiting a page with <applet> tag
> It seems that all keyboard layouts using the "Unicode" script are affected,
> while all others aren't.

Thanks for pointing this out.  It'll help me deal with the problem when I get
back.

>>> This happens with the default keyboard layout for my Powerbook, which is
>>> shift_jis.
>>
>> Odd.  Do you have problems with any of the Japanese input methods?
>
>Please notice that the comment you quoted above was not from me, and is
>probably describing an unrelated issue.

I did notice.  I was just being lazy and addressing both you (Uri) and
philippe in the same message :-)

By the way (and I'm addressing this to Uri), I get the impression that the
Java Embedding Plugin (from mentions I've seen on the web) has a number of
users in the languages whose keyboards don't work, including Hebrew.  I'll
have to look into this when I get back.  But for the time being I wonder if
_all_ users of Unicode keyboards are effected.


With the Japanese keyboard active.

After visiting the URI above, I immediately had the following problems/symptoms: spacebar doesn't scroll the page, FAYT stops working (cannot be activated by pressing the / key); attempting to close the tab or window (I tried both) via the keyboard fails -- and at the first visit, the browser froze solid. Failing also: switching tabs form the keyboard (command 1 or 2 or 3,..). Some other keyboard shortcuts still work (back/forward, copy-paste into another application, but using the mouse to select text).

The failures propagated to any of the open tabs.

Attempting to input text in a textarea fails (as described in comment 0). Both with 'Romanji' (Roman text input) and Japanese input method.

I tested this both as a 'Japanese' user (OS language: Japanese) and an 'English' User (OS language: English).

With the US keyboard active: keyboard kept working, none of the symptoms above. But then I tried to input text in a textarea, and switching to Japanese input midway, the keyboard immediately stopped working.

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20051030 Firefox/1.6a1 ID:2005103005

I couldn't reproduce this with Camino (2005091409 build).

PS - other keyboard related problems I mentioned in my first message are unrelated to this case indeed. I did mention them as it was not clear where the problems described by Uri where coming from.
I've just reproduced this with the latest Fx branch nightly and the Roman-but-Unicode "US Extended" layout and the "Unicode Hex Input" and Inuktitut keyboard layouts, so I think it's safe to that all keyboard layouts of the "Unicode" type are affected :-(

This doesn't happen in Camino--however, it has its own share of Unicode keyboard layout issues, bug 152721 and bug 244658; smfr makes some broad stabs at the issues in the latter, which may or may not help you, Steven, when you try to diagnose the issue in the JEP and the wonderful world of Cocoa).
Josh, can you help us investigate here?
josh, if you get more data on this, renominate it.
Flags: blocking1.8rc2? → blocking1.8rc2-
If this is a JEP problem we probably need smichaud to look at it since he is the only person who really deals with that code. Not much we can do at the moment, and in any case I recommend leaving this as not blocking. If smichaud gets back and can give us a fix for a possible rc2, maybe we should then just land a fixed JEP. JEP tends to be solid, and we could do a bunch of testing. Too bad we didn't find this earlier!

Not renominating at least until smichaud posts a fix.
I've just released a new version (0.9.5+b) of the Java Embedding Plugin that
fixes this problem (plus a couple of other relatively minor ones).

http://javaplugin.sourceforge.net/

Please try it out, and let me know your results.

I'm particularly anxious to hear from people (like Uri and Phillippe) who use
Unicode keyboard layouts on a daily basis.  I tested as thoroughly as I could
on the US Extended keyboard layout ... but that's not the one I normally use.

(I don't expect, Phillippe, that this update will fix all the problems you
listed, even in your shorter list.  If some problems remain, they should
probably be covered in one or more separate bug reports.)

If no-one has turned up any major problems after a day or two of testing, I'll
renominate this as a 1.8rc2 blocker.

Recent Firefox versions (since sometime in August) bundle older versions of
the Java Embedding Plugin.  The best way (I think) to test them with JEP
0.9.5+b is to follow the JEP Readme's instructions to install JEP 0.9.5+b
(JavaEmbeddingPlugin.bundle and MRJPlugin.plugin) to your /Library/Internet
Plug-Ins/ directory, then remove the bundled JEP files (the same ones) from
the Firefox distro's Contents/MacOS/plugins/ directory.

What broke the Unicode keyboard layouts was a bug in the Java Embedding Plugin
-- which turned out to be quite easy to fix.

I don't know how I managed to miss such an important problem.  And I'm
_appalled_ that no-one else ever reported it to me -- even though it makes the
Java Embedding Plugin (basically) unusable in quite a few languages.

Oh well, such is life.  At least the problem was caught before Firefox 1.5 was
released.

I tested JEP 0.9.5+b (following the instructions in the comment above) and it does indeed fix the problem for me with the hebrew keaboard.

Please renominate this for blocking 1.8. If 1.8 is released without this fix, I think we'll have to recommend to users of international keyboards to disable Java altogether (this was my "workaround" until I installed the new JEP).
Severity: normal → major
Renominataing, see comment 17 and comment 18.
Flags: blocking1.8rc2- → blocking1.8rc2?
(In reply to comment #17)

Ok, it is weird. I first tried on the desktop G4, with the 20051107 branch build. That worked correctly. The problems listed in my comment #12 have disappeared.

Then I tried the same on the 20051107 Trunk build (1.6a1) on my Powerbook, and this failed partly. The same problems still occur, when Japanese is active. US extended works fine.

Both computers are running 10.3.9. I can't think of any difference between the two machines.
(In reply to comment #17)
> then remove the bundled JEP files (the same ones) from
> the Firefox distro's Contents/MacOS/plugins/ directory.

Note that when you do this and are doing partial updates, when the new JEP actually lands and you get the partial update, Fx does not install the JEP part of that update for some reason--at least that seemed to the case on the nightly [1.8 branch] update channel the last time I did this (when the unexpected 10.3.9 Java update hit).

I'll watch for this when/if JEP 0.9.5+b hits the 1.8 branch, and if others are also paying attention, it'll help to see if it was just an anomaly before....
Smokey, do you mean bug 313700?
Because this bug disables Java in so many languages, I'd say it should be
considered critical.  I also think it should block the release of Firefox 1.5
and of RC2.

Uri's tests show that the Unicode keyboard layout problem has been fixed
... and so (I think) do Phillippe's.

I didn't have any problems with the DeerPark 2005-11-08-10-trunk nightly (with
its old JEP removed and replaced by JEP 0.9.5+b in /Library/Internet
Plug-Ins/), using either the US Extended keyboard or the Japanese Katakana and
Hiragana input methods (I tested the latter both with and without conversion
to Chinese characters).  Even Phillippe didn't have any problems with a recent
branch nightly, and I suspect his remaining problems on the trunk have some
other cause.  And the US Extended keyboard worked for him even with the trunk
build.  (One question I have is how to choose a Shift-JIS keyboard layout -- I
don't see it among any of the choices.  But this should probably be taken up
in a separate bug.)

JEP 0.9.5+b should be landed on the trunk and branches as soon as possible,
and as far as possible in advance of a presumed RC2.  The idea is to get it to
a moderately large group of testers before it goes out to the huge number that
will download RC2.

I just opened bug 315637, "New version of JEP (0.9.5+b), please land on trunk
and branch".
Severity: major → critical
I minused the JEP bug but we'll have to revist that decision if we decide to slip the release and respin for this bug. At this point we're far enough along with the release that I don't believe we are going to slip for this bug.
(In reply to comment #23)

The thing is, Japanese, Chinese and Hangul are not strictly keyboard layouts, but input methods, and you use roman characters to input i.e. Japanese. When any of those input methods are active (their icon showing in the menubar), the keyboard 'breaks' after loading a java-applet.

This is on a 'stock' Powerbook as sold in Japan, or with the Apple 'shift_jis' extended external keyboard connected to the Powerbook. Apple lables both as 'shift_jis' keyboard.

Should I file an extra bug for this ?


(In reply to comment #22)
Mark, no, not bug bug 313700.  I meant that if I remove the JEP from inside Fx (like we've done to test this bug), when the partial update that contains the new version of the JEP arrives, the rest of the update is applied but the new JEP is not installed into the Fx bundle.  At least that's what seemed to happen before.
(In reply to comment #25)

> The thing is, Japanese, Chinese and Hangul are not strictly keyboard
> layouts, but input methods

I know.  I'm quite familiar with how the Chinese and Japanese input methods
work (I use them a lot myself).

> Should I file an extra bug for this ?

Yes.  But I now have substantial other claims on my time, and may not be able
to get to it for a while.

Also, I probably will never be able to test on an "Apple 'shift_jis' extended
external keyboard".

I'm disappointed that the fix for this bug won't (apparently) make it into the
Firefox 1.5 release.  Incorporating the fix would (at most) delay RC2 by a
couple of days.  But not having it is going to create serious problems for
people using Firefox 1.5 on the Mac in Arabic, Hebrew, Greek, Persian, Thai,
the South Asian languages, Turkish and Vietnamese (to name only the languages
with the largest number of speakers).

I concur with Steven's comment. Shipping a product which is fundamentally broken (in a tricky and non-intuitive way) when we have a fix at hand seems to me like the wrong thing to do.

People will discover they sometimes can't type into the browser - meaning effectively that they can't use it. They're unlikely to discover a solution or workaround, and they're most likely to just get frustrated and switch to a different browser - maybe never to come back.
Bug Triage mtg: This requires unicode keyboard and java app on Mac.  Not a large use case.
Flags: blocking1.8rc2? → blocking1.8rc2-
We've got final bits in hand and this is going to have to wait for the follow-up release. We should get this release noted and plan on taking the JEP update for 1.8.1.
(In reply to comment #27)

I filed bug 315972 for the problems with East-Asian input methods.



(In reply to comment #31)
> We've got final bits in hand and this is going to have to wait for the
> follow-up release. We should get this release noted and plan on taking the JEP
> update for 1.8.1.

Asa, when you said "the follow-up release" did you mean 1.8.0.1, or 1.8.1 (which, if I understood correctly, means Firefox 2.0)?
I really hope it's the former.
Flags: blocking1.8.1?
Flags: blocking1.8.0.1?
Since bug 315637 has landed on trunk, shouldn't this bug be marked as fixed?
Uri:  Is there a workaround for this bug?  If so, if anyone can provide us with more information, we would like to get it into the relnotes for 1.5.  Thanks!
Whiteboard: relnote?
(In reply to comment #35)
> Uri:  Is there a workaround for this bug?  If so, if anyone can provide us with
> more information, we would like to get it into the relnotes for 1.5.  Thanks!

The only workaround I know of is to manually remove the version of JEP bundled with Firefox, and then install JEP 0.9.5+b (or later). The details for how to do so are provided in comment #17 (4th paragraph from the end). 
*** Bug 320248 has been marked as a duplicate of this bug. ***
Drivers: I vote aye on this for 1.8.0.1/1.5.0.1.  It's brutal.
If I'm understanding this correctly, this is dependent on landing the latest version of JEP on the branch, which is bug 315637.

In addition, since JEP has already landed on the trunk, this bug should be marked resolved fixed (again, if I'm understanding correctly).
(In reply to comment #39)
> If I'm understanding this correctly, this is dependent on landing the latest
> version of JEP on the branch, which is bug 315637.
> 
> In addition, since JEP has already landed on the trunk, this bug should be
> marked resolved fixed (again, if I'm understanding correctly).

Yes, you are correct on both accounts. I'm resolving this FIXED.
Still, this might be the right place for discussing fixing this for 1.5.0.1.
Status: NEW → RESOLVED
Closed: 18 years ago
Depends on: 315637
Resolution: --- → FIXED
Flags: blocking1.8rc2-
Flags: blocking1.8.1?
Flags: blocking1.8.0.1?
Target Milestone: --- → mozilla1.8.1
*** Bug 309769 has been marked as a duplicate of this bug. ***
Status: RESOLVED → VERIFIED
Keywords: fixed1.8.0.1 → verified1.8.0.1
*** Bug 322043 has been marked as a duplicate of this bug. ***
Could it be fixed for 1.5.x too, please?
This was fixed by JEP 0.9.5+b, which was landed long ago on the trunk
and branches (see bug 315637 comment 6).  This JEP was bundled with
Firefox 1.5.0.1, if I remember correctly.

So whatever problem you're having, it's not this one.

It's possible that you're experiencing one of the problems that was
fixed by the latest version (0.9.5+g) of the Java Embedding Plugin,
which hasn't yet made it into any Firefox releases.  (See item #1 of
attachment 230956 [details] at bug 346156.)

Otherwise please open a new bug.  And when you do so, please be sure
to provide enough information -- for example which version of Firefox
you're using, on which version of Mac OS X, and step-by-step
instructions for causing the problem to happen using publicly
available URLs.

This bug is marked verified1.8.0.1, which corresponds to Firefox 1.5.0.1.
OK, this is bug 347041.
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.