User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; fr; rv:1.9.0.1) Gecko/2008070206 Firefox/3.0.1 Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; fr-FR; rv:1.9.1a2pre) Gecko/2008072800 Lightning/0.6a1 Shredder/3.0a2pre when one try to use the tag hotkey for instance "Remove All Tags" by pressing the azerty key combination SHIFT+à (=0), the tag is not apllied. If one use the "verr num" capability of the keyboard, by pressing the key "," the tag is applied correctly. Reproducible: Always Steps to Reproduce: 1. open Thunderbird (Shredder v3.0a2pre) 2. select any mail 3. on an azerty keyboard, press SHIFT+& (=1) 4. The message is not tagged as IMPORTANT Actual Results: The message is not tagged as IMPORTANT Expected Results: The message should be tagged in regards to the tag hotkeys configuration 0 : remove all tag 1 : IMPORTANT etc... I have lightning and gcal provider add-ons but I don't think there's anything linked with this.

does this happen with TB v2?

No, add a flag in TB v2 works fine with AZERTY keyboard. Paul

do you see this trunk regression?

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b1pre) Gecko/20081003 SeaMonkey/2.0a2pre using Belgian AZERTY keyboard (where digits on top row are shifted) Hit 1 (i.e. Shift+&) => no effect Hit Keypad-1 (in NumLock mode) => Message line in List pane becomes red I'm not sure what the comma refers to in relation with "verr num" in comment #0 -- note that "verrouillage numérique" or "verr num" is French for Num Lock. Moving to MailNews Core (because common to Tb and Sm) but not sure I found the right "Component".

P.S. Build ID: 20081003001423

This sounds very much like bug 359638 (the Core regression) -> bug 429219 (the FF fix) > bug 432002 (the "wanted" SM port)...

Simon, are you planning on working on this bug?

If this is the same as bug 359638/bug 429219, Masayuki is probably a better owner than me.

Oh, this needs to change core widget code on all platforms. Because we don't send alternative keycodes by gecko keypress event without modifier key pressing... So, the changes may be too risky for Fx3.1. Are we using different branch for Tb3 and Fx3.1?

(In reply to comment #10) > So, the changes may be too risky for Fx3.1. Are we using different branch for > Tb3 and Fx3.1? They will be the same branch (mozilla-1.9.1).

(In reply to comment #10) > this needs to change core widget code on all platforms. Because we don't > send alternative keycodes by gecko keypress event without modifier key > pressing... Can/should this be solved by adding modifiers="shift any" to the appropriate key element? https://developer.mozilla.org/En/XUL/Key Maybe these are the elements? http://mxr.mozilla.org/comm-central/source/mailnews/base/resources/content/mailWindowOverlay.xul#405 Or/and these? http://mxr.mozilla.org/comm-central/source/mail/base/content/mailWindowOverlay.xul#436

Ah, it's good idea.

Has a faint whiff of hackiness to it, but it's not like using unmodified numbers as commandkeys is one of the platform's most common things.

Despite the simplicity of karlt's solution, my memories of key hell the first make me really want to slip this in before b2 for maximum exposure.

Comment on attachment 362509 [details] [diff] [review] Fix v.1 Conveniently we don't expose these shortcuts in the UI, instead we leave the user to guess them by making them the access keys in the tags submenu.

Rub it in, Mr. My Platform Actually Shows Accesskeys In Menus - on OS X, we just mash random combinations while trying to see what might have changed.

Comment on attachment 362509 [details] [diff] [review] Fix v.1 Looks reasonable, r=mkmelin