User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.0.1) Gecko/20021029 Chimera/0.5+ Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.0.1) Gecko/20021029 Chimera/0.5+ Form controls marked with accesskey parameters don't respond to the access keys. Reproducible: Always Steps to Reproduce: 1. Go to the Bugzilla query page. 2. Try to use an accesskey. Actual Results: Try command. Control. Option. Shift-all of the above. None trigger it.
Yeah, I don't think accesskeys were ever fixed on Mac. There's probably a bug about it somewhere...
You mean bug 122479. Hmm. Dup? Should this be covered by that bug?
confirming. not sure if this is a dup of bug 122479...
this appears to be a problem within chimera, as it's not a problem in mozilla --trunk or 1.0.2 branch. here's another test case, where Ctrl-1 (and ctrl-2, Ctrl-3, etc) will focus the textfields in the form (in mozilla, but not chimera): http://www.cs.hmc.edu/~jruderma/s/ i think bug 122479 is a similar but different bug, which prolly affects both chimera and mozilla on mac.
The problem affects also links: try http://www.francocarcillo.it/dive/accessibility_statement.html The acceskeys don't work. I'm using Build ID: 2003042705 The same keys work fine on Mozilla 1.3 (Gecko/20030312) ACCESSIBILITY IS A MUST!
Confirming with 2003082402
Camino is a fine, /fine/, browser ... but this accesskey problem is the only reason I'll venture back to Safari now and then. (There's one website I frequent for which the accesskeys are muscle memory now.)
Could either Jasper, Mike, or Stuart please explain what is going on with this bug? Why is there a nib that removes a delete icon that was never added? Do we just need to land a little cleanup patch? It seems to me we should have a delete button and the edit menu should work. Either way this bug should be easy to knock off the 0.9 list.
That last comment of mine is posted in the wrong bug... ignore it.
Neat idea for Accesskey application. Forgive me if the wrong place. http://www.mozdev.org/pipermail/camino/2004-March/001696.html
Ping. This hasn't yet been marked as a 09 blocker, but I think it *needs* to be ready by then. Has anyone taken a look at it recently?
I'm pinging this again. No one's touched it and it's an 09 blocker. Can someone look more into this? How hard is this to implement? If it's not something that should be in 09 (or can be in 09 due to time constraint), let's move it to 1.0.
Created attachment 187266 [details] Fix cocoa event dispatching to correctly handle control-modified key events This patch fixes access keys by making sure that we dispatch the correct KEY_PRESS events when the control key is down. The patch also contains some renaming of the various -convert: methods to reduce reader confusion, and guts nsChildView::ModalEventFilter(), since that is all bogus code.
Oy Simon, it appears you only attached a testcase and no actual patch.
Created attachment 187291 [details] [diff] [review] The patch this time.
Aside from the fact that the patch doesn't apply, the following concerns me: /Users/josh/src/camino_opt/mozilla/widget/src/cocoa/nsChildView.mm: In function `void -[ChildView mouseUp:](ChildView*, objc_selector*, NSEvent*)': /Users/josh/src/camino_opt/mozilla/widget/src/cocoa/nsChildView.mm:2569: warning: ` ChildView' may not respond to `-convert:message:toGeckoEvent:' /Users/josh/src/camino_opt/mozilla/widget/src/cocoa/nsChildView.mm:2569: warning: cannot find method `-convert:message:toGeckoEvent:'; return type `id' assumed
Created attachment 187429 [details] [diff] [review] updated to trunk, warnings not fixed yet
Created attachment 187440 [details] [diff] [review] Updated patch to trunk
Checked in. Thanks!
Er, this was landed, so removing the obsolete ? flag. Sorry for the noise.