And when I build WebKit and run it in Safari, only ctrl+alt work. Weird. I'm doing testing now to see what this fixes.
Avi On Thu, Mar 5, 2009 at 4:38 PM, Avi Drissman <[email protected]> wrote: > That value gets set in WebKit's WebFrame.mm: > > if ([[NSApp > accessibilityAttributeValue:NSAccessibilityEnhancedUserInterfaceAttribute] > boolValue]) > AXObjectCache::*enableEnhancedUserInterfaceAccessibility*(); > > What is that mysterious NSAccessibilityEnhancedUserInterfaceAttribute? It's > a secret AppKit value, equaling @"AXEnhancedUserInterface". What's *that*? > > Oh, it's a magical value set by VoiceOver as a hint to certain internal > AppKit controls to alter their behavior slightly to make life better for it. > (See > http://lists.apple.com/archives/accessibility-dev/2006/Feb/msg00009.html). > That message is the only documentation past seeing it in WebKit archives. > > I'm fine with this, but I just want to know how I can do both... > > Avi > > > > On Thu, Mar 5, 2009 at 4:34 PM, Thomas Van Lenten > <[email protected]>wrote: > >> Does the universal access setting w/in safari's prefs change this in any >> way? >> >> TVL >> >> >> >> On Thu, Mar 5, 2009 at 4:30 PM, Avi Drissman <[email protected]> wrote: >> >>> I'm trying to figure out the exact meaning of >>> accessibilityEnhancedUserInterfaceEnabled because I'm getting that effect on >>> my Mac without any accessibility. In addition, what I forgot to mention is >>> that *both* ctrl *and* ctrl+alt work in Safari for me, while we can only >>> pick one to return from accessKeyModifiers() and whichever one we don't >>> return doesn't work. >>> >>> Avi >>> >>> >>> On Thu, Mar 5, 2009 at 4:24 PM, Ben Goodger (Google) >>> <[email protected]>wrote: >>> >>>> It sounds like they only use the single modifier when the >>>> accessibility system setting is turned on, otherwise they use the dual >>>> one. Why don't we just do the same thing? I'm pretty sure we should >>>> match the platform default browser instead of emacs. >>>> >>>> -Ben >>>> >>>> On Thu, Mar 5, 2009 at 1:22 PM, Avi Drissman <[email protected]> wrote: >>>> > The definition of what the accesskey modifier is the result of >>>> > EventHandler::accessKeyModifiers(). On Windows it's alt, and on >>>> Chromium >>>> > it's also alt. >>>> > >>>> > The question is: What to make it on the Mac? And how to do it right? >>>> > >>>> > Mozilla apparently switched recently to use the command key. They used >>>> to >>>> > use the control key. What does Safari use? Much more difficult >>>> question. The >>>> > code says: >>>> > >>>> >> unsigned EventHandler::accessKeyModifiers() >>>> >> { >>>> >> // Control+Option key combinations are usually unused on Mac OS >>>> X, but >>>> >> not when VoiceOver is enabled. >>>> >> // So, we use Control in this case, even though it conflicts with >>>> >> Emacs-style key bindings. >>>> >> // See <https://bugs.webkit.org/show_bug.cgi?id=21107> for more >>>> >> detail. >>>> >> if (AXObjectCache::accessibilityEnhancedUserInterfaceEnabled()) >>>> >> return PlatformKeyboardEvent::CtrlKey; >>>> >> >>>> >> return PlatformKeyboardEvent::CtrlKey | >>>> PlatformKeyboardEvent::AltKey; >>>> >> } >>>> > >>>> > And if you go to the layout test, you'll see that on the Mac it uses >>>> the >>>> > modifiers ctrl+alt. This solution is problematic for two reasons. >>>> > >>>> > The first is that using a dual modifier sucks. It makes it extremely >>>> > difficult to use accesskeys. >>>> > >>>> > The second is that triggering them with a single modifier (just the >>>> ctrl >>>> > key) on my machine works fine in Safari. Which puts me in a quandary, >>>> > because I'm not sure how Safari's doing that (I'm digging now). If we >>>> alter >>>> > our accessKeyModifiers() to return the dual modifier, layout tests >>>> start >>>> > passing, but it's hard to use. If we use just ctrl, then it's easy to >>>> use >>>> > but we fail tests. And somehow Safari does both... >>>> > >>>> > Avi >>>> > >>>> > > >>>> > >>>> >>> >>> >>> >>> >>> >> > --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
