User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a4pre) Gecko/20070422 Minefield/3.0a4pre Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a4pre) Gecko/20070422 Minefield/3.0a4pre Entries (single-line, multi-line, password) have an Activate action which can be performed through AT-SPI. Performing this action consistently fails for multi-line entries. Reproducible: Always Steps to Reproduce: 1. Launch Firefox, navigate to bugzilla.mozilla.org and bring up a form to enter a new bug 2. Click somewhere in the text of the page to activate the caret. I clicked on the line beginning with "Look through the search results." 3. Launch Accerciser and navigate in the hierarchy to the Details multi-line entry. With this item highlighted in Accerciser: 4. In the IPython Console entry type: actions = IAction(acc)<return> success = actions.doAction(0)<return> print success<return> 5. Alt Tab back to the Firefox window. Actual Results: Success is False and the caret remains wherever you placed it in step 2. Expected Results: Success would be True and the caret would have moved into the Details entry. If you repeat the process for a single-line entry on the same page, you will get the expected results namely success will be True and the caret will move into that entry.

Should it do the same thing as grabFocus()?

> Should it do the same thing as grabFocus()? Well, that depends.... :-) Right now, given an entry (single-line, multi-line, password) there are a couple of behaviors I've noticed with grabFocus() with respect to updating the position of the caret within the document frame: Behavior 1: If the current location in the document frame is some non-linked text, performing a grabFocus() on an entry will move you to that entry so that you can type, AND it will update the location of the caret to that entry. If you then press Tab, you will move to the next focusable object that follows the entry. This is exactly what I would want and expect to occur. Behavior 2: If the current location in the document frame is a link, performing a grabFocus() on an entry will move you to that entry so that you can type, BUT it will not update the location of the caret. If you then press Tab, you will move to the next focusable object that follows the link. This is not what I would want, nor is it what I would expect. The activate action for single-line and password entries seems to always update the caret position to the entry regardless of whether you are in text or on a link. That is what I would like it to do in multi-line entries. I saw that there were at least a couple of bugs related to grabFocus(). I have not yet had the time to look at them closely enough to see if they address Behavior 2. That's on my to-do list. That said, if Behavior 2 is a bug, and if grabFocus() will consistently update the caret position to the entry, then the answer to your question is "yes." :-)

Minor adjustment to Behavior 1: > If you then press Tab, you <strike>will </strike> often, but not always, > move to the next focusable object that follows the entry.

Comment on attachment 263959 [details] [diff] [review] Use more general nsIDOMNSHTMLElement::focus() instead of nsIDOMHTMLInputElement::focus(). The more general interface applies to both textarea and input. Looks good to me. (BTW it looks like nsHTMLInputElement::Focus just calls nsGenericHTMLElement::SetElementFocus anyways)