Bug 26995 – AX: Some webpages do not send AXLoadComplete

• Component: Accessibility
• Status: RESOLVED FIXED

[chris fleizach]

some webpages are not sending AXLoadComplete notifications

[Greg Hughes]

Created attachment 32332 [details]
Proposed patch

Patch ensures that the AXCache is updated with the current document before posting the AXLoadComplete notification.

[chris fleizach]

you could probably cache renderer()
you might want to add a comment saying why we need to do this

[Darin Adler]

Comment on attachment 32332 [details]
Proposed patch

Code change looks fine. Needs comment explaining why it's calling getOrCreate and discarding the result. Needs a ChangeLog.

review- because of those issues

[chris fleizach]

greg, also run the prepare-ChangeLog script and re-submit the patch (along with comments), which will obviate this patch

[Greg Hughes]

Created attachment 32350 [details]
Updated patch

patch updated to cache renderer() and include a comment

[Greg Hughes]

Created attachment 32351 [details]
Updated patch 3

Updated patch based on review

[Darin Adler]

Comment on attachment 32351 [details]
Updated patch 3

> +    RenderObject* render = renderer();

An idiom we use for this is

    RenderObject* renderer = this->renderer();

The downside of naming the variable "render" is that's a verb with a different meaning.

Is there any way to make a regression test for this?

r=me

[chris fleizach]

for a regression test... what if we stored the last notification to be sent in AXObjectCache. then in the layout test we could have a mechanism to ask for the last notification, which would allow us to ensure it was sent. 

it seems like we might want to also add an ASSERT checking that there is an ax object available before posting the notification, so that we might catch other cases where this is happening

[Darin Adler]

(In reply to comment #8)
> it seems like we might want to also add an ASSERT checking that there is an ax
> object available before posting the notification, so that we might catch other
> cases where this is happening

We can't do that until we fix the real problem, because we know that assert will fire.

[chris fleizach]

i was not able to write a layout test for this because i need the layout test to stall until it the notification gets posted. unfortunately, the layout tests get run and exited before the notification is actually sent.

[chris fleizach]

http://trac.webkit.org/changeset/45602

[Darin Adler]

(In reply to comment #10)
> i was not able to write a layout test for this because i need the layout test
> to stall until it the notification gets posted. unfortunately, the layout tests
> get run and exited before the notification is actually sent.

That's something we can tackle later; it can be overcome so we can make a test for this. You can call layoutTestController.waitUntilDone() to prevent the layout test machinery from moving on to the next test until layoutTestController.notifyDone() is called. Then you just have to figure out how to get some JavaScript code called once the test truly is done.