seamonkey build 2004082909 on WinXP steps to reproduce this bug : 1 go to http://www.forosdelweb.com/ (it's a web design forums site) 2 logon, select a message and click on the "responder" icon to put your answer (in fact, get into any form field) 3 Introduce a Spanish character with alt+168(¿) for instance exected result : spanish character inserted actual result : you are redirected to http://www.forosdelweb.com/index.php? The site is using vBulletin which has accesskeys for common functions (going to home page, the FAQ, the search page...) and these fonctions are now triggered when you try and insert characters with their code number. Site is now unusable.
asking it as a blocker to the final release, there are lots of vBulletin sites around...
Oy vey, another problem with accesskeys. I suggest that accesskeys shouldn't work from digits typed on the numeric keypad, since those are what's used to type in the extended ascii chars. Good solution?
I'd like to see a fix for this at some point, i've noticed it on other places now.
*** Bug 316893 has been marked as a duplicate of this bug. ***
*** Bug 308061 has been marked as a duplicate of this bug. ***
Someone on the mozillazine forums just posted a great workaround for this issue: - turn OFF the NumLock. Alt+NumPad symbols and foreign characters can still be entered, without any issue. (NumLock obviously needs to be turned on again if you wish to use it to enter numbers).
That doesn't seem to work for me. With Num Lock off, Alt-Num4 is back, Alt-Num6 is forward, and probably some other things. Having the numbers behave as arrow keys rather than numbers interferes with built-in Firefox access keys rather than the vBulletin ones.
(In reply to comment #7) > That doesn't seem to work for me. With Num Lock off, Alt-Num4 is back, > Alt-Num6 is forward, and probably some other things. Having the numbers behave > as arrow keys rather than numbers interferes with built-in Firefox access keys > rather than the vBulletin ones. Hmm.. damn - yes, you're right: 4 & 6 swap pages still. The 3 or 4 symbols & accented letters I tried before posting worked ok. So it's not a good solution.. This is still marked as 'P3-major'. As a regression, I would have thought that this issue's importance should have already been bumped up at least a few notches.. but alas, it's been around far too long. Who knows.. if it doesn't get fixed soon, some people might switch to Netscape 8.1 (Gecko 1.7.5.. not broken)
(In reply to comment #8) > Who knows.. if it doesn't get fixed soon, some people might switch to Netscape > 8.1 (Gecko 1.7.5.. not broken) Well, that would be a bit extreme. We're talking a rather limited number of users here (must regularly use vB *and* regularly use numeric character code entry). Still, it is rather obnoxious.
This is annoying for me as I have a US keyboard and live in the UK. I like to type the £ symbol.
I have the same problem. Every time I try to enter a letter that has tilde on them, such as á é í ó ú or ñ, Firefox simply jumps to another page. It happens only when in a forum that uses VBulletin. This Firefox bug has been outstanding for a very long time. Very annoying!
Woohoo - I just thought I'd revist a few Bugs now that I'm trying out FF2.0b2 (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1b2) Gecko/20060821 Firefox/2.0b2 - Build ID: 2006082101) --- and am happy to report that IT APPEARS TO BE RESOLVED! Try the vbulletin test forum (no membership required): http://www.vbulletin.com/forum/forumdisplay.php?f=15 Didn't try the forum mentioned by the Bug Reporter as it requires signing up - but I verified on a few sites the still non-working status on FF1.5.06 and then tried them again on 2.0betas and all appears ok. If someone with powers would like to verify and close the bug, let's cross this one off the list!
Yawn - it's been over 3 months since my last post requesting this Bug's status be updated to "FIXED". Shall I file a separate Bug? ;o)
Created attachment 250172 [details] testcase (In reply to comment #13) > this Bug's status be updated to "FIXED". This bug isn't FIXED at all. At best is has become superficially WORKSFORME due to the fact that content accesskeys now require an additional Shift key. The attached testcase demonstrates two issues: 1. Enabling NumLock and then hitting Numpad7 and Numpad 1 while Alt is pressed doesn't produce the expected character ("G") but still triggers the accesskey. 2. XUL menus don't respect key.ui.contentAccess (Aaron: has a bug for this issue been filed already?) This bug covers the first of the two issues which is about ignoring Numpad numbers entered while Alt is pressed -- which is how Windows in general and notably Internet Explorer in particular behave.
(In reply to comment #14) > This bug isn't FIXED at all. At best is has become superficially WORKSFORME due > to the fact that content accesskeys now require an additional Shift key. > > The attached testcase demonstrates two issues.... > This bug covers the first of the two issues which is about ignoring Numpad > numbers entered while Alt is pressed -- which is how Windows in general and > notably Internet Explorer in particular behave. Thanks for the long-awaited reply, even if it wasn't what I wanted to hear! I tried your testcase, and yes, I see what you mean. It's strange then that as of FF2.0, the originally filed-issue of entry of Alt+NumPad international characters or symbols on sites such as vBulletin forums (which have a few accesskeys declared) - is now fixed where it was broken before. (I just tested it again using the originally-reported site, 'forosdelweb.com' - FF18.104.22.168 not working, FF2.0 works - the site itself has not changed). Looking at the sourcecode of a page from the 'forusdelweb.com' site, it uses: <td class="vbmenu_control"><a href="search.php?do=getnew" accesskey="2">Nuevos Mensajes</a></td> (and so on) .. I'm no expert, but there's nothing unusual or specific in style to vBulletin (or your testcase) that I can see that might result in different behaviours. You(Simon) mentioned a SHIFT-key modifier, which I was not even aware of. So I tested it out - and discovered that on the same 'forosdelweb' vBulletin forum example, Alt+Shift+Num (not NumPad, but the Number keys just above QWERTYUIOP) works as intended for triggering the site's assigned accesskeys, but Alt+Shift+NumPad does not. Was it meant to? If "no", then why the need for a SHIFT-modifier on the Num keys? UNmodified Alt+Num presses aren't assigned to anything, are they? If "yes", well - it doesn't work. In fact, while testing this out, I discovered something even more strange(undocumented in Windows and/or FF) -- in FF and *even in IE7* pressing Alt+Shift+7(<-NumPad) on any page triggers the browser's 'Home Page', while Alt+Shift+4 (<-NumPad) triggers 'Back'(1 page). You don't even have to have the cursor in a text box. Additionally, and perhaps even more strange, again with *both* browsers, on *some* pages, including any vBulletin forum page or even this Bug report page - pressing Alt+Shift+6(NumPad) *also* triggers the 'Home Page', while doing the same on some other pages (such as Google.com) - does *not*. I did a Google search but could not come up with anything saying why these little-known and therefore little-used triggers are enabled in Windows (XP, anyhow). But as long as Alt+Shift+4,6,or7 on the NumPad are 'pre-assigned' by Windows, it would seem to indicate that the NumPad and accesskeys should not mix. Microsoft's solution for IE is simple, intuitive, non-conflicting. Why not copy it?
(In reply to comment #15) > It's strange then ... As I said: due to the changes from bug 340902, this is has become "superficially WORKSFORME". > Alt+Shift+NumPad does not. Was it meant to? Not really. In combination with certain modifiers NumPad keys are supposed to work differently than keys on the alphanumeric keyboard part. > If "no", then why the need for a SHIFT-modifier on the Num keys? Reading the reasoning behind bug 340902 should answer that question. > I discovered something even more strange ... You might want to read your keyboard's documentation on that strangeness: Shift is known to reverse the effect of NumLock and toggle between numbers and navigation (i.e. end/down/page down/left//right/home/up/page up from 1 to 9). > it would seem to indicate that the NumPad and accesskeys should not mix. Amazingly, through all the strangeness you've been observing, you still come to the right conclusion. ;) Exactly that's what a patch to this bug shall look like.
Mass un-assigning bugs assigned to Aaron.