Steps to reproduce: 1. Open the attached test case and launch Accerciser 2. Examine each entry using Accerciser's Interface viewer Expected results: Each of the four entries would have "editable" among their states. Actual results: With the 5th July trunk build (14), the second entry lacks this state. Beginning with the 6th July trunk build, the first and the second entry lack this state. For some reason, the presence of certain Javascript scripts associated with a form can prevent editable entries and password text in that form from exposing STATE_EDITABLE.

I think it's caused by the contentEditable changes. The first textfield get focused by javascript, so we creates accessible for first 2 textfields immediately after the page loaded. GetEditor fails at that time for some reason. http://lxr.mozilla.org/seamonkey/source/accessible/src/html/nsHTMLFormControlAccessible.cpp#561

We hit NS_ERROR_DOM_SECURITY_ERR http://lxr.mozilla.org/seamonkey/source/content/html/content/src/nsGenericHTMLElement.cpp#3841

interesting, the regression of first text field happened between July 3 to July 4 the regression of second text field happened between July 5 to July 6

actually I think it's a little random.

The summary of this bug is very nice! javascript focus() caused nsCaretAccesible::NotifySelectionChanged be called, and then we creates accessible objects for the textfields. because the js is on JSStack, we're denied to get the editor. Is it a false denial?

If there's untrusted JS on the stack, the denial is correct. You probably want to push a null JSContext on the stack before doing the GetEditor() call. Not sure why contentEditable would affect this.

Maybe contentEditable is not related to this.

Comment on attachment 273538 [details] [diff] [review] patch >Index: nsHTMLFormControlAccessible.cpp >+ // Override UniversalBrowserWrite capability by pushing a null jscontext That's not what you're doing. You're making sure that you're not restricted by the permissions of whatever script is currently running. >+ stack->Push(nsnull); That call can fail, and if it does you need to deal with that. You do NOT want to pop if pushing failed.

Looks better now? BTW: the last patch is copied from extensions/webservices/security/src/nsWebScriptsAccess.cpp#767 which is an example in http://wiki.mozilla.org/Breaking_the_grip_JS_has_on_the_DOM

Comment on attachment 273549 [details] [diff] [review] patch v2 Much better, thank you!

Comment on attachment 273549 [details] [diff] [review] patch v2 Ginn, can you provide a more complete description of what is going on? I don't understand it. Why is JS involved here at all? Please add the description in the comments when you check in.

One thing I want to understand is why we don't have this problem in other areas of mozilla/accessible, not just when dealing with the editor, but for any calls we make.

Most calls you make probably don't do explicit security checks like GetEditor() does.

Theoretically we can get similar things everywhere where untrusted js is a cause of events we handle if I get right.

I guess there're somewhere else in mozilla/accessible need a similar patch, I think we can find out later.

committed