639835 - EVENT_DOCUMENT_LOAD_COMPLETE may be not fired at startup

Status: REOPENED

(Core :: Disability Access APIs, defect)

Description

[Fernando Herrera]

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

Comment 1

[Fernando Herrera]

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

Comment 2

[Fernando Herrera]

However this happens to me with any home page.

Comment 3

[Fernando Herrera]

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

Comment 4

[alexander :surkov (:asurkov)]

(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?

Comment 5

[Fernando Herrera]

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)

Comment 6

[alexander :surkov (:asurkov)]

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?

Comment 7

[Fernando Herrera]

We are not even creating nsApplicationAccessibleWrap.

Comment 8

[alexander :surkov (:asurkov)]

(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"?

Comment 9

[Fernando Herrera]

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
        ...

Comment 10

[alexander :surkov (:asurkov)]

(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?

Comment 11

[Fernando Herrera]

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

Yes

Comment 12

[alexander :surkov (:asurkov)]

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

Comment 13

[Fernando Herrera]

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.

Comment 14

[alexander :surkov (:asurkov)]

nsWindow::Create is called too late?

Comment 15

[Fernando Herrera]

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.

Comment 16

[alexander :surkov (:asurkov)]

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?

Comment 17

[alexander :surkov (:asurkov)]

Fernando, sounds like regression, could you please check?

Comment 18

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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

Comment 19

[alexander :surkov (:asurkov)]

(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?

Comment 20

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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

Comment 21

[alexander :surkov (:asurkov)]

(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?

Comment 22

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Yes I think so.

Comment 23

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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

Comment 24

[Fernando Herrera]

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.

Comment 25

[Fernando Herrera]

This is the related change stopping the window activation:

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

Comment 26

[Fernando Herrera]

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.

Comment 27

[alexander :surkov (:asurkov)]

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

Comment 28

[Fernando Herrera]

Attachment: Create Root accesible onShow

Something like this should work.

Comment 29

[Robert O'Callahan (:roc) (email my personal email if necessary)]

BTW can we have an automated test for this?

Comment 30

[alexander :surkov (:asurkov)]

(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.

Comment 31

[Fernando Herrera]

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)

Comment 32

[alexander :surkov (:asurkov)]

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

Comment 33

[Fernando Herrera]

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.

Comment 34

[alexander :surkov (:asurkov)]

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?

Comment 35

[alexander :surkov (:asurkov)]

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

Comment 36

[BugBot [:suhaib / :marco/ :calixte]]

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.