[Bug 802926] Re: firefox starts out inaccessible! (assuming default home page)

Bug Watch Updater 802926 at bugs.launchpad.net
Thu Jun 30 08:22:18 UTC 2011

Launchpad has imported 35 comments from the remote bug at

If you reply to an imported comment from within Launchpad, your comment
will be sent to the remote bug automatically. Read more about
Launchpad's inter-bugtracker facilities at

On 2011-03-08T16:05:03+00:00 Fernando Herrera wrote:

As reported on this thread:


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

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

Reply at: https://bugs.launchpad.net/firefox/+bug/802926/comments/0

On 2011-03-08T23:00:15+00:00 Fernando Herrera wrote:

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

Reply at: https://bugs.launchpad.net/firefox/+bug/802926/comments/1

On 2011-03-08T23:03:30+00:00 Fernando Herrera wrote:

However this happens to me with any home page.

Reply at: https://bugs.launchpad.net/firefox/+bug/802926/comments/2

On 2011-03-08T23:18:52+00:00 Fernando Herrera wrote:

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

Reply at: https://bugs.launchpad.net/firefox/+bug/802926/comments/3

On 2011-03-09T08:27:43+00:00 Alexander Surkov wrote:

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

Reply at: https://bugs.launchpad.net/firefox/+bug/802926/comments/4

On 2011-03-09T09:43:02+00:00 Fernando Herrera wrote:

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

Reply at: https://bugs.launchpad.net/firefox/+bug/802926/comments/5

On 2011-03-09T12:20:41+00:00 Alexander Surkov wrote:

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?

Reply at: https://bugs.launchpad.net/firefox/+bug/802926/comments/6

On 2011-03-09T12:52:24+00:00 Fernando Herrera wrote:

We are not even creating nsApplicationAccessibleWrap.

Reply at: https://bugs.launchpad.net/firefox/+bug/802926/comments/7

On 2011-03-09T12:56:04+00:00 Alexander Surkov wrote:

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

Reply at: https://bugs.launchpad.net/firefox/+bug/802926/comments/8

On 2011-03-09T13:15:14+00:00 Fernando Herrera wrote:

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


Reply at: https://bugs.launchpad.net/firefox/+bug/802926/comments/9

On 2011-03-09T13:21:50+00:00 Alexander Surkov wrote:

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

Reply at: https://bugs.launchpad.net/firefox/+bug/802926/comments/10

On 2011-03-09T13:22:47+00:00 Fernando Herrera wrote:

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


Reply at: https://bugs.launchpad.net/firefox/+bug/802926/comments/11

On 2011-03-09T13:36:25+00:00 Alexander Surkov wrote:

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

Reply at: https://bugs.launchpad.net/firefox/+bug/802926/comments/12

On 2011-03-09T13:43:25+00:00 Fernando Herrera wrote:

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.

Reply at: https://bugs.launchpad.net/firefox/+bug/802926/comments/13

On 2011-03-09T15:12:06+00:00 Alexander Surkov wrote:

nsWindow::Create is called too late?

Reply at: https://bugs.launchpad.net/firefox/+bug/802926/comments/14

On 2011-03-09T20:08:09+00:00 Fernando Herrera wrote:

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.

Reply at: https://bugs.launchpad.net/firefox/+bug/802926/comments/15

On 2011-03-10T03:07:55+00:00 Alexander Surkov wrote:

Robert, we try to create document accessible when window is created
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?

Reply at: https://bugs.launchpad.net/firefox/+bug/802926/comments/16

On 2011-03-10T03:10:45+00:00 Alexander Surkov wrote:

Fernando, sounds like regression, could you please check?

Reply at: https://bugs.launchpad.net/firefox/+bug/802926/comments/17

On 2011-03-10T03:50:30+00:00 Roc-ocallahan wrote:

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

Reply at: https://bugs.launchpad.net/firefox/+bug/802926/comments/18

On 2011-03-10T07:04:13+00:00 Alexander Surkov wrote:

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

Reply at: https://bugs.launchpad.net/firefox/+bug/802926/comments/19

On 2011-03-10T08:23:08+00:00 Roc-ocallahan wrote:

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

Reply at: https://bugs.launchpad.net/firefox/+bug/802926/comments/20

On 2011-03-10T08:25:34+00:00 Alexander Surkov wrote:

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

Reply at: https://bugs.launchpad.net/firefox/+bug/802926/comments/21

On 2011-03-10T08:34:33+00:00 Roc-ocallahan wrote:

Yes I think so.

Reply at: https://bugs.launchpad.net/firefox/+bug/802926/comments/22

On 2011-03-10T08:35:01+00:00 Roc-ocallahan wrote:

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

Reply at: https://bugs.launchpad.net/firefox/+bug/802926/comments/23

On 2011-03-10T10:18:10+00:00 Fernando Herrera wrote:

With this one, a11y tree is not created without focus:

However, this one:

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.

Reply at: https://bugs.launchpad.net/firefox/+bug/802926/comments/24

On 2011-03-10T10:20:53+00:00 Fernando Herrera wrote:

This is the related change stopping the window activation:


Reply at: https://bugs.launchpad.net/firefox/+bug/802926/comments/25

On 2011-03-10T10:28:36+00:00 Fernando Herrera wrote:

So before this change:


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

Reply at: https://bugs.launchpad.net/firefox/+bug/802926/comments/26

On 2011-03-10T10:31:12+00:00 Alexander Surkov wrote:

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

Reply at: https://bugs.launchpad.net/firefox/+bug/802926/comments/27

On 2011-03-10T12:39:24+00:00 Fernando Herrera wrote:

Created attachment 518335
Create Root accesible onShow

Something like this should work.

Reply at: https://bugs.launchpad.net/firefox/+bug/802926/comments/28

On 2011-03-23T04:22:02+00:00 Roc-ocallahan wrote:

BTW can we have an automated test for this?

Reply at: https://bugs.launchpad.net/firefox/+bug/802926/comments/29

On 2011-03-23T04:27:58+00:00 Alexander Surkov wrote:

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

Reply at: https://bugs.launchpad.net/firefox/+bug/802926/comments/30

On 2011-03-24T14:24:26+00:00 Fernando Herrera wrote:

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)

Reply at: https://bugs.launchpad.net/firefox/+bug/802926/comments/31

On 2011-05-28T11:35:28+00:00 Alexander Surkov wrote:

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

Reply at: https://bugs.launchpad.net/firefox/+bug/802926/comments/32

On 2011-05-30T11:44:18+00:00 Fernando Herrera wrote:

According to this user feedback:


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

Reply at: https://bugs.launchpad.net/firefox/+bug/802926/comments/33

On 2011-05-31T08:59:33+00:00 Alexander Surkov wrote:

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?

Reply at: https://bugs.launchpad.net/firefox/+bug/802926/comments/34

** Changed in: firefox
       Status: Unknown => Confirmed

** Changed in: firefox
   Importance: Unknown => Medium

You received this bug notification because you are a member of Mozilla
Bugs, which is subscribed to Mozilla Firefox.

  firefox starts out inaccessible! (assuming default home page)

To manage notifications about this bug go to:

More information about the Ubuntu-mozillateam-bugs mailing list