This applies to any text input widget in M5. I cannot test this on any other platform. If you run Win98 with the keyboard layout set to US-International (with so-called dead keys) entering a dead key results in a space being displayed. You can still past text that contains quotes, just not enter them in apprunner directly. This is not covered in the Release notes or Bugzilla as far as I can see...

This is invalid. I use that keyboard layout on a daily basis and have had no problems.

Marking verified. The following line is typed using the US-International keyboard layout: Ich weiß nicht was soll es bedeuten / Daß ich so traurig bin Ein Märchen aus alten Zeiten...

I am reopening this bug because the fact that you don t see the problem doesnt not imply that it does not exist. I am available if you need more information, Im just not sure what more I could give you.

gelderen, I'm not sure what else to check. I have tested against Windows 98 on a H-P Vectra and Compaq Deskpro 590, and against Windows NT 4 on a Vectra and Dell Dimension XPS R400. When you say it 'doesn't work', in what sense doesn't it work? Can you be more specific? On all of these machines, I am able to click into any field and type anything with the US-International keyboard layout. And you are familiar with the quirks of this layout, right? (ie you have to press '-space to get the ' character, and so on...)

Clearing target milestone (M5 is a past milestone and therefore not valid).

btw, what do you mean by 'dead key'? (i just noticed that part of your original comment, sorry - and yes, we're working on better textarea wrapping in mozilla!)

When Im typing, the dead keys are simply ignored. (Normally a single quote would have showed up in the second word of the sentence.) If I type a dead key followed by a space (to force display) all I get is a space. Copying that space into a hex-editor reveals that it really is a space (0x20). At the same time, dead keys work in my other programs, just not in Apprunner. The machine is an IBM Thinkpad 560Z Running Win98 (4.10.1998). I can give a dump of the Microsoft System Information if thats helpful. I can also run diagnostics if you have something that could be helpful. Now a weird thing that I just noticed is that sometimes entering a single quote indeed shows a single quote. I cannot reliably reproduce this, however :-( Ill try and find out more of course...

Oops, accidentally reverted the milestone. Back to M15 it is...

A dead key is a key that does nothing when typed (single quote, double quote, apostroph, tilde). It will only show up when the next character is entered. This is from typewriter idiom where a dead key would appear but not advance(wording?) paper. Just to check: arrow keys and 'end and delete dont work either on my machine. And as you can see in the previous sentence slipped trough. Weird... Chatting in Bugzilla is fun, isnt it? ;-)

Lo and behold, I was wrong. There are indeed problems with the US-International keyboard layout on Windows 98. (My problem was that my keying method was different that gelderen's.) Here's how to reproduce this: build ID: 1999050408 platform: windows 98 1. Set your keyboard layout to US-International in the Keyboard control panel. 2. Open a page in apprunner with a text input control. Start typing. Try these things: Using the US-International keyboard layout requires you to press Space after typing certain characters to type the character itself. For example, if you type the single quote key, if you type a after it, you get á. If you type a space after it, you should get '. However, behavior is very inconsistent in apprunner. To get that single quote, I had to type single quote-space about ten times and then delete the extra spaces. Additionally, when you follow a modifier (what gelderen calls a dead key, I think) with a letter that cannot be modified by it - for example, if you follow the single quote with the letter M - you should then get 'm. So... In apprunner: Following a modifier or dead key with a space should give you the modifier itself. Try this with the tilde, single quote, or double quote (to name a few). However, it usually just gives you a space. Following a modifier with a character it can't modify should insert the modifier and the character into the text input control - for example, typing I-single quote-m should give you I'm. However, apprunner usually gives you Im. I have been unable to reproduce this on NT, but it's definitely a problem under Windows 98. gelderen, thanks for the bug. in the future, however, please be as explicit as possible... prevents us from closing things just based on the summary line! :)

FYI: I was running build 1999050423 when I detected the problem.

Tague, I'm going to send this your way. I don't know if it belongs to you and widget code you're doing or to some widget guy like Rod. I'll let you reassign as necessary.

okie - i'll try to take a look at this soon.

this should be fixed with the patch that i am waiting on. the patch fixes a bunch of things related to keyboard input, i18n, unicode, and windows.

bulk move to M9

Was this fixed by Tague's key event fixes from last Sunday?

No, it was not fixed. I just tested build 1999061509-win32 with a bugzilla form.

Can you please verify this against Ender. Right now, we/I am not supporting the non-Ender text widgets since they are going to go away. I would like to know if (and i'm assuming it has been) the problem has been fixed for Ender - or if I have more work to do there. If it's fixed for Ender, we can close it out once Ender replaces the other text widgets.

moving to M10 to reflect bug fixing priorities

could someone please verify if this problem occurs with ender or not

Using the 1999071908 build under Windows 98, this problem happens in Ender.

I'm not sure when this changed, but this is now no longer working on Windows NT as well (I used SP 5). Upgrading severity as this negatively impacts my ability to use the product.

can you give me a detailed script of what you are trying and the unexpected results that you are getting. this is getting tested with russian, greek, german, and japanese keyboard and i haven't seen any incorrect behavior. i will look at this over the weekend to see if someone hasn't introduced a regression.

tague, the bug described in this bugzilla report has never been fixed AFAIK. Look at the 11th description 'lo and behold...' to see exactly how you can reproduce this problem. You don't need weird keyboards for this, just use a US keyboard and set it's layout to US-International (in the Control Panel on Windoze). Then try and type some text with accents in any text field (for example in the URL-textfield). I've verified that this problem still exists in Apprunner 1999082412 on Win98 (4.10.1998) and I have never seen a build in which it was fixed. I check builds daily or every other day.

tague, this has never worked for me on Windows 9x, and as of late it isn't working for me on Windows NT either. Once again, to reproduce: 1. In Windows, select Settings | Control Menu from the Start menu. 2. Open the Keyboard control panel. 3. Click the Language tab. 4. Click the Properties button. 5. Change the Keyboard Layout to US-International. 6. Click OK. Click OK again to exit the Keyboard control panel. 7. Launch Notepad and the latest build of Apprunner. 8. In Notepad, try typing words with accents/diacritics, eg naïve, San José, schön, sueño. You do this by typing a dead key followed by the character you wish to modify - eg ~+n = ñ, "+o = ö, '+e = é. 9. Switch to Apprunner. Select File | New | Blank Window to bring up an Editor window. Now, try typing those same words. Result: you can't. You just get blank spaces instead of the desired characters. If that isn't specific enough, please call me (check the internal company phonebook) and I would be happy to do a demo for you next week. Thanks!

thanks that helps alot - i kept trying to fix something different. sorry for all the trouble.

*** Bug 12393 has been marked as a duplicate of this bug. ***

okay, it should be fixed now. i got confused about the us-international layout thing, i thought you were refering to different keyboard layouts in general (like on the mac) not dead keys. i tested this with various combinations of acute, grave, and tildes.

Today's build (1999083108) crashes whenever I click into the body of the browser; until that bug (12743) is fixed I can't verify this fix.

I will verify as soon as the Windoze builds work again. (They crash on startup now.)

Reopening and clearing resolution. Using the 1999090208 build under Windows 98, I saw these results: - Typing "-o displayed 'o' and not 'ö' - Typing RightAlt-S displayed nothing and not 'ß' In short, it hasn't been fixed.

As off today I can no longer type dots (.) in any text control in Mozilla. This is 1999091914 on Win98. I'm not filing this in a new bug because it may be related. It certainly is annoying :-)

Underscores (_) are also AWOL in current builds, but those are covered in another bug. Periods are working under NT but I'm not sure about 95/98... gelderen, I'd just as soon file another bug on the periods if that's reproducible on the 1999092013 build under 95/98 (if tague et alii have nothing against it). Thanks again, gelderen, for your continued contributions!

I spoke too soon it appears, dots work in 1999092008. That version however refuses to show me http://bugzilla.mozilla.org/show_bug.cgi?id=6053 :-) Oh well, typing in 4.6 now, I'll keep an eye on in and maybe file a bug later. I'm now going to look for a bug describing the alt-tab problem as that drives me crazy during browsing. (The problem being that on alt-tab to another Mozilla window, the File menu is selected. This wouldn't be a problem if it weren't for the fact that clicking in the Location field doesn't switch the input focus -> every character you type now selects a menu. Grr.) I think the latter problem may be related to this bug too...

tague is doomed, reassign this to myself.

Mark it as M11 assigned. Add tague/buster/akkana/rods to the cc list

I look at this bug and try it with the fix I have for bug 15657/11845. The part which is still broken is AltGR and Shift+AltGR.

fix in keyEvent_19991004_BRANCH landing

Using the 1999101411 build under Windows NT, both dead keys and the AltGR key work (nearly) as expected (well, the AltGR key also activates the menus, but this is great!). Using the same build under Windows 98, dead keys do NOT work in text input controls, but the AltGR key does (but the menus are dropped down as well, alas). So, this is NOT fixed in the 1999101411 build under Windows 98. ftang, in which build should this be fixed?

*** Bug 10901 has been marked as a duplicate of this bug. ***

Using the 1999101508 build under Windows 98, dead keys are still broken (although the AltGR key is working OK). Reopening and clearing resolution.

cpratt: 1.Can the follow table represent the current status ? WinNT: AltGr Work. Dead Key Work Win98:AltGr Work. Dead Key Does Not Work Win95: ? 2. Can you try this keyboard with NotePad in Win98 and see does the dead key work there ?

In response: > 1.Can the follow table represent the current status ? > WinNT: AltGr Work. Dead Key Work > Win98:AltGr Work. Dead Key Does Not Work > Win95: ? Yes, that's it. AltGR now works on all Win32 OSes. Dead keys are not working on Windows 98 or Windows 95. > 2. Can you try this keyboard with NotePad in Win98 and > see does the dead key work there? The dead keys work as expected in every other Windows app I've tried, including Notepad.

down grade the problem to P2 M11

M12? This is a VERY important problem for non-US English users...

ok... change it to M11...

Putting on [PDT+] radar.

In message composition in M11- 29/10/99 release under Windows 98, when compoosing a message in Greek (ISO-8859-7), the keyboard key for accents is not functional.In text composition the accent ´ (which is the accent in greek and supposed to appear after entering a character) do not works at all.

really do not have time to fix for M11. Move to M12

You might want to ask the Javasoft folks as I seem to recall having seen the same bug in their early AWT implementations. Sorry for not having more details :-(( (But happily writing CSS2 pages that actually *work* :-))

I don't know why the behavior is different between NT and 9x, but are we handling the sequence of messages correctly: WM_KEYDOWN WM_DEADCHAR WM_KEYUP WM_KEYDOWN WM_CHAR WM_KEYUP According to http://msdn.microsoft.com/library/psdk/winui/keybinpt_7r1v.htm, typically an app ignores the 1st 2 messages and then process the 2nd wm_char message. I searched http://lxr.mozilla.org/seamonkey/ and did not find any wm_deadchar. Do we need to catch these messages and clear up state from the wm_keydown?

Un(fortunately) I don't have a Windoze SDK installed, but I experimented a little in the URL box in the latest Mozilla build. It appears that the dead keys are 'eaten' by Mozilla, unless you type fast. If you rapidly enter a sequence of 'e' followed by '\'' you'll see something like "eeeeeeeeeééeeeeeeeéééééééeeee" appearing. Can fast typing lead to losing WM_XXXX messages? Will a lost message lead to the showing up of 'é's? Maybe-related-note: SDK says that WM_CHAR is generated after WM_KEYDOWN but WM_DEADCHAR is generated upon WM_KEYUP. http://leb.net/wine/WinDoc/msdn/sdk/platforms/doc/sdk/win32/mess/src/msg23_13.ht m http://leb.net/wine/WinDoc/msdn/sdk/platforms/doc/sdk/win32/mess/src/msg22_9.htm

Is this a problem with how we are processing the WM_xxx event messages on Windows in http://lxr.mozilla.org/seamonkey/source/widget/src/windows/nsWindow.cpp Reassigning to joki.

Sorry it took me a couple days to get to this again but I don't think this is mine. I handle events passed in from the widget library. If the bug is in the widget library it belongs to widget people which would be either the Windows widget library owner, a rather fuzzy category right now but it was rods for a while, or i18n people working on the Windows widget library which I believe is ftang. For now I'll go back to ftang as he worked on this stuff last.

I know I should own this bug. I don't know why bobj reassign this to joki.

I am not sure this is different from NT and 95/98 now. I can see the same problem in my NT on Location bar now. It is fine on my NT in form, composer, platin text editor. cpratt- could you try this again in your 95/98 against 1. URL bar 2. text field in html form 3. composer 4. plain text editor 5. Mail subject field ?

cpratt out for two weeks, eli can you help frank out?

Build: 1999111408 on Win98 1. URL bar - buggy 2. text field in html form - buggy (bugzilla, enter email address) 3. composer - crash, can't test 4. plain text editor - crash, can't test 5. Mail subject field ? - crash, can't test

[Sure. QA Assigning to self, due to cpratt's vacation + change of role.]

Frank, does the information provided by gelderen@mediaport.org answer your cpratt query, or would you like me to check using a newer build? Thanks!

It should fix now. Please test again.

Verified fixed in Composer using the 1999120315 build under Windows 98. gelderen, if you see this anywhere else... thanks!

Commit pushed to master at https://github.com/mozilla/bedrock https://github.com/mozilla/bedrock/commit/bebad9158aa8795a45f2a4025a0f1f8d953192e4 Add channel to system requirements page title mozilla/bedrock/issues#6053