Thanks! Your suggestions sound great, and I'll let you know when I've finished changing the code.
I didn't even realize an enum was possible in an extension api. That sounds great. I also thought it would be nice if the names matched equivalent names already used in the html dom where possible, like "button" and "checkbox". - Dominic On Fri, Dec 18, 2009 at 11:48 AM, Erik Kay <[email protected]> wrote: > I some comments to the code review, but I'll summarize the API pieces for > those following here. > > The main issue is that I think there's a little too much overloading going > on: > * ControlInfo feels like it should be split into more concrete subtypes > with separate parameters. > * onOpen/Close should be split into onWindowOpen/onMenuOpen, etc. > * type parameters should use a formal enum > > Erik > > > On Wed, Dec 16, 2009 at 10:20 PM, Erik Kay <[email protected]> wrote: > >> +chromium-dev >> >> On Wed, Dec 16, 2009 at 1:15 PM, Dominic Mazzoni <[email protected]>wrote: >> >>> Hi, >>> >>> Here's an experimental proposal I'd like to throw out there. All types >>> of suggestions, criticism, and questions are welcome. >>> >>> - Dominic >>> * >>> * >>> *Overview* >>> This experimental API exposes information about focused controls in the >>> native ui, like dialog boxes and the location bar. Specifically, it allows >>> an extension to determine the current focused control and listen to events >>> such as changing focus, selecting controls, and text editing. It optionally >>> allows for generating keyboard events, too. >>> >>> Existing screenreaders on Mac, Windows, and Linux do a good job of >>> exposing simple dialog boxes, but a poor job of exposing complicated web >>> pages. Javascript-based screenreaders can often provide much better support >>> for browsing the web, but are poor at exposing the user interface of the >>> browser. This solution empowers javascript-based screenreaders. >>> >>> *Use cases* >>> 1. Build a complete screenreader as a Chrome extension, similar to the >>> "FireVox" screenreader for Firefox (see http://www.firevox.clcworld.net/). >>> This would enable developers to create custom accessibility solutions for >>> people with all sorts of special needs, using JavaScript, that will run on >>> Chrome on any platform. >>> >>> 2. Enable pure-javascript testing of browser user-interface elements, >>> like interacting with controls in a dialog box. This could potentially >>> simplify some ui tests. >>> >>> *Could this API be part of the web platform?* >>> No. >>> >>> *Do you expect this API to be fairly stable?* >>> Yes. >>> >>> *What UI does this API expose?* >>> It does not have a UI of its own. >>> >>> *How could this API be abused?* >>> I hope that exposing information about focused controls and listening to >>> focus and text editing events should not be risky; most of the information >>> in these controls is already exposed via other APIs. >>> >>> Enabling automation of keyboard events is risky; a malicious extension >>> could control the user's browser. This should only be enabled for trusted >>> extensions or via a flag. >>> * >>> **How would you implement your desired features if this API didn't >>> exist? >>> *** >>> The only way to provide accessibility or UI automation now requires >>> writing platform-specific, low-level code that is beyond the reach of most >>> developers. This API could enable new innovation in accessibility. >>> >>> *Are you willing and able to develop and maintain this API?* >>> Yes. >>> >>> *Draft API spec* >>> This changelist contains the API spec and an implementation that exposes >>> information about most of the controls in the Options dialog for GTK: >>> http://codereview.chromium.org/402099 >>> * >>> * >>> In a nutshell, the proposed API exposes two functions: >>> * getFocusedControl >>> * simulateKeyPress >>> >>> and five events: >>> * onOpen (for a dialog or context menu, for example) >>> * onClose >>> * onFocus >>> * onSelect >>> * onText >>> >>> Accessibility APIs such as MSAA on Windows are significantly more >>> complicated than this, as they need to support a huge range of possible >>> applications, including applications that were not designed with >>> accessibility in mind. The main reason that this API can be much simpler is >>> that we assume that the entire user interface is already accessible via the >>> keyboard (or should be). Instead of allowing tools to traverse the user >>> interface hierarchy and determine how it should be presented to a disabled >>> user, we can just expose information about the control the user has >>> navigated to using the existing keyboard commands. >>> * >>> * >>> >> >> > -- You received this message because you are subscribed to the Google Groups "Chromium-extensions" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/chromium-extensions?hl=en.
