Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a6pre) Gecko/2007060802 SeaMonkey/2.0a1pre I'm using a Norwegian keyboard, and trying to type the tilde (~) sequence does not work anymore. It's normally typed by holding the AltGr key while pressing ¨ (key top left of the enter key) Borrowing product component and keywords from bug 341308, where it was also broken (a year ago)

I guess this is still broken with a current trunk build?

Oh yes, still broken in Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a7pre) Gecko/200707131111 SeaMonkey/2.0a1pre Which is the latest nightly for Windows. (Linux and Mac builds are three days newer though)

Do you know when this regressed? All AltGr key combos seem to work though on my German keyboard, including the ~ char (which is also AltGr + top left key of enter key here). Confirming anyway as you see this bug.

Sorry - no idea when it happened. (Used 1.7 during the year bug 342810 was alive) Strange it works on your machine. I've double checked that it isn't my keyboard. Thought I'd check another profile and see there, but can't seem to change profiles anymore?

I just installed Minefield 3.0a8pre after Firefox 1,5 refused to start, and I'm having the same problem, on a Swedish keyboard. All the other AltGr combos seems to work, except for tilde (which is the one I use the most)

Cannot type the tilde character with: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9a8) Gecko/2007091216 GranParadiso/3.0a8 Windows Vista 32b Pro French with a French (AZERTY) keyboard

I have experienced the same problem. It has worked perfect for all version of Mozilla Firefox 2.0.x, but is a problem in the Edit Box (in my particular case when editing a Wikipedia page) on both Beta 1 and Beta 2 of Firefox 3.0.

(In reply to comment #7) > I have experienced the same problem. It has worked perfect for all version of > Mozilla Firefox 2.0.x, but is a problem in the Edit Box (in my particular case > when editing a Wikipedia page) on both Beta 1 and Beta 2 of Firefox 3.0. > One additional little tidbit. It seems to work if I switch to US-English keyboard.

Related misfunction using Spanish keyboard. Normal usage (other apps and FF 2.0.0.11): AltGr+4 prepares ~ to be shown, just like accent characters, if i then press 'a', 'o', etc get ã, õ. Any other key: show ~ + otherkey. This includes a second AltGr+4 which should give ~~ Firefox 3b2: Pressing AltGr+4 prepares to show it. A second AltGr+4 does nothing (set it again on buffer?). Other uses are fine. Other keys with this behaviour (´^`) correctly are doubled when pressed again.

neil is this something you can take a look at?

Mozilla/5.0 (Windows; U; Windows NT 5.1; sv-SE; rv:1.9b3) Gecko/2008020514 Firefox/3.0b3 Swedish keyboard. Normally you can type two tildes by pressing AltGr+¨ twice (under windows anyway). In FF3 beta 3 however, if you want a tilde you have to type AltGr+¨ and then space. Makes it kind of annoying to use on wikis as you sign your comments with ~~~~...

If I switch to a Norwegian keyboard layout, pressing Control+Alt+], then pressing ] alone (the ] is the key in the equivalent position to the umlaut key): displays a tilde followed by the umlaut character. This same happens in some other applications as well. If this is a regression, it would be very helpful to find the regression range.

Using norwegian layout with norwegian keyboard: The problem per today is exactly what you see: the tilde doesn't "take effect" when typed (with the proper combo). But when I key in the ¨ it appears - *together* with the ¨. So I suddenly get ~¨ Another problem, with a current build: When keying in the ¨ alone, nothing happens. When keying it once more, two ¨ appears. So: nothing on first key sequence on that key - and two on the next, whatever was typed. The same goes for the ^ These three are all located on the same key on a Norwegian keyboard: ¨ (no modifier) ^ (shift) ~ (altgr) SImilar to what Johan observed: If i add a space after the first key (sequence), the desired token will appear, but the space is NOT typed.. it "vanishes". When I originally filed this bug, however, adding a space had no effect! I couldn't lure out a tilde for my bare life. So not only has it regressed, but the regression has changed between builds 2007060802 and 2008022302 (both nightlies, trunk) The reason I am aware of the "space" trick is because this is a common global bug on Linux (in the OS keyboard setup/interpretation as such, not Mozilla!) And in whichever app the tilde etc. fails there, it normally types when adding a space. But this is Windows. Can't remember seeing these bugs here before. Sorry I can't be more helpful with the timeline.

ERRATA! I see it in other apps on Windows as well - notepad prints two at every second key'ing, WfW on additional space. Guess I don't use tilde except in the browser on Windows.

masyauki: can you take a look at this? renominate if critical

This bug is simple. The key is VK_OEM_1 and printable. So, the WM_CHARs are removed in nsWindow::OnKeyDown for shortcut keys handling. But the dead key combination should not be any shortcut. So, we should not remove the WM_CHARs at that time.

Stuart: This is too critical for the keyboard layout users. This should be blocker. And the patch is simple, but pretty risky. Because I cannot test on all keyboard layouts and all key combination. So, I hope this fixes on b4 and it should be tested on many testers.

Not blocking beta 4 on this, moving to P1 based on comment 17 which implies requirement for some beta testing.

Ere: Note that if I changed: if (DOMKeyCode == NS_VK_RETURN || DOMKeyCode == NS_VK_BACK || ((mIsControlDown || mIsAltDown) && KeyboardLayout::IsPrintableCharKey(aVirtualKeyCode))) to if (DOMKeyCode == NS_VK_RETURN || DOMKeyCode == NS_VK_BACK || ((mIsControlDown || mIsAltDown) && !gKbdLayout.IsDeadKey() && KeyboardLayout::IsPrintableCharKey(aVirtualKeyCode))) It doesn't work fine.

(In reply to comment #19) > Ere: > > Note that if I changed: > > if (DOMKeyCode == NS_VK_RETURN || DOMKeyCode == NS_VK_BACK || > ((mIsControlDown || mIsAltDown) && > KeyboardLayout::IsPrintableCharKey(aVirtualKeyCode))) > > to > > if (DOMKeyCode == NS_VK_RETURN || DOMKeyCode == NS_VK_BACK || > ((mIsControlDown || mIsAltDown) && !gKbdLayout.IsDeadKey() && > KeyboardLayout::IsPrintableCharKey(aVirtualKeyCode))) > > It doesn't work fine. Oops, sorry this is my mistake. the code works fine. I'll attach the new patch.

I'm sorry. This is more simple patch. And works fine for me.

Comment on attachment 306522 [details] [diff] [review] Patch v2.0 r=me

checked-in.

Reporter: I don't have the right type of keyboard to verify this bug. Would like kindly verify that it works? Thanks.

It now works the same way as in other editors on Windows. It's fixed - thank you. Tested with trunk 2008030902 SeaMonkey/2.0a1pre

I reported bug 412312 and the issue I saw is indeed also fixed (im using swedish keyboard layout). I verified it in Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9b5pre) Gecko/2008031109 Minefield/3.0b5pre