firefox starts out inaccessible! (assuming default home page)

As reported on this thread:

https://mail.gnome.org/archives/orca-list/2011-March/msg00033.html

Sometimes orca cannot navigate for the google webpage when firefox has been just launched with google.com as its homepage. Next pages or reloads work fine.

That may happen because orca is not getting the document:load-complete event (our EVENT_DOCUMENT_LOAD_COMPLETE).

I cannot reproduce it here, but I'm investagating it

I finally found a way to reproduce it.

It happens when firefox window is not focused when launched. I can do this under GNOME for example having a terminal window with the "always on top" activated and launching firefox from a panel launcher or Alt+F2 dialog. In that case firefox opens, requests the focus to the window manager (metacity won't give it because of the focus stealing prevention) and no document:load-complete is fired.

Doing the same with firefox 3.6 and it fires the document:load-complete

However this happens to me with any home page.

Actually we are not firing _any_ event until the window is focused.

(In reply to comment #3)
> Actually we are not firing _any_ event until the window is focused.

on atk I guess? We should change that, correct?

Humm, not sure. What happens is that we do not create the accessible tree until the window gets activated. In gtk that happens after:

nsWindow::OnContainerFocusInEvent --> DispatchActivateEventAccessible --> DispatchEventToRootAccessible(nsIAccessibleEvent::EVENT_WINDOW_ACTIVATE)

On the another hand if we handle notification then document accessible should be created and we shouldn't miss any event. Do we or atk ignores events until window active event isn't handled?

We are not even creating nsApplicationAccessibleWrap.

(In reply to comment #7)
> We are not even creating nsApplicationAccessibleWrap.

nsAccplicationAccessible is created on demand (for example, when root accessible is created), but why do you say "even"?

Because in gtk/atk we are not creating _any_ accessible element until we get the first DispatchEventToRootAccessible(nsIAccessibleEvent::EVENT_WINDOW_ACTIVATE)
that triggers:

accService->GetRootDocumentAccessible
  nsAccessNode::GetApplicationAccessible
    nsApplicationAccessibleWrap
      nsApplicationAccessible
        ...

(In reply to comment #9)
> Because in gtk/atk we are not creating _any_ accessible element until we get
> the first
> DispatchEventToRootAccessible(nsIAccessibleEvent::EVENT_WINDOW_ACTIVATE)
> that triggers:

do you mean nobody request for accessibility service before this, correct?

(In reply to comment #10)
> do you mean nobody request for accessibility service before this, correct?

Yes

Can we detect that accessibility is enabled or presence of AT?

Yes, actually we are checking it at atk nsApplicationAccessibleWrap::Init and gtk nsWindow::Create to call CreateRootAccessible. That last call looks like the guilty here.

nsWindow::Create is called too late?

no, when nsWindow::Create is called, nsWindow::CreateRootAccessible tries to get the accesible with nsWindow::DispatchAccessibleEvent, but at nsWebShellWindow::HandleEvent docShell is null, so it never calls to presShell->HandleEventWithTarget for getting the accessible.

Robert, we try to create document accessible when window is created (http://mxr.mozilla.org/mozilla-central/source/widget/src/gtk2/nsWindow.cpp#4205) by sending accessible event (nsIWidget::DispatchEvent) but nsWebShellWindow is not ready to handle events yet (per comment #15). Can we send an accessible event later when we can be sure it can processed correctly?

Fernando, sounds like regression, could you please check?

Can you make nsWebShellWindow::HandleEvent handle the event itself?

(In reply to comment #18)
> Can you make nsWebShellWindow::HandleEvent handle the event itself?

Yes, but it's neccessary to get nsIDocument associated with the window (also it should pass conditions in http://mxr.mozilla.org/mozilla-central/source/accessible/src/base/nsAccDocManager.cpp#414, in case of timing issues). Is there a way since docshell is not initialized yet?

No. Maybe you should send the event when the nsPresShell for the root document is created?

(In reply to comment #20)
> No. Maybe you should send the event when the nsPresShell for the root document
> is created?

does it guarantee the widget (native window) is created at this point?

Yes I think so.

Another option, maybe an easier one, is to send the event when we first show a toplevel window in nsIWidget::Show.

With this one, a11y tree is not created without focus:
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2009/09/2009-09-16-03-mozilla-central/

However, this one:
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2009/09/2009-09-15-03-mozilla-central/

creates it because it forces the window to get the focus and a11y tree is created. This forcing focus thing is hiding want we want to know without debugging every build. As 3.6 is not forcing the focus, I'll try going back to check is the change is not hidden.

This is the related change stopping the window activation:

http://hg.mozilla.org/mozilla-central/rev/329ff0fcd420

So before this change:

http://hg.mozilla.org/mozilla-central/rev/cabb8925dcd3

(that forced window activation) we were not creating the a11y tree, that makes me wonder why 3.6.14 is not forcing window activation but creating the tree on time.

If there's no any problem with absent window activation on focus, then I suggest to follow Robert suggestion from comment #23.

Created attachment 518335
Create Root accesible onShow

Something like this should work.

BTW can we have an automated test for this?

(In reply to comment #29)
> BTW can we have an automated test for this?

perhaps tests on Orca side would work, especially if we want to get tinderbox for that.

I think testing on the orca side would work better, as we cannot really prevent window having focus on mochitest (but running with orca/other app window on top can do it)

landed - http://hg.mozilla.org/mozilla-central/rev/9260bd59d5ce

According to this user feedback:

http://mail.gnome.org/archives/orca-list/2011-May/msg00431.html

it fixes the main problem, but introduces some other problem. So it would need further investigation/testing.

Fernando, are you sure these problems are related? If I read the user feedback right then he tells about broken accessible name. I think it's worth to file follow up for this.

Marco, doesn't the issue sound familiar to you?

Trevor, could you look at comment #33 please? Is it related with this bug?

Clear a needinfo that is pending on an inactive user.

Inactive users most likely will not respond; if the missing information is essential and cannot be collected another way, the bug maybe should be closed as `INCOMPLETE`.

For more information, please visit [auto_nag documentation](https://wiki.mozilla.org/Release_Management/autonag#inactive_ni_pending.py).