Launchpad has imported 35 comments from the remote bug at https://bugzilla.mozilla.org/show_bug.cgi?id=639835.
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 https://help.launchpad.net/InterBugTracking. ------------------------------------------------------------------------ On 2011-03-08T16:05:03+00:00 Fernando Herrera wrote: 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 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 --> DispatchEventToRootAccessible(nsIAccessibleEvent::EVENT_WINDOW_ACTIVATE) 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: accService->GetRootDocumentAccessible nsAccessNode::GetApplicationAccessible nsApplicationAccessibleWrap nsApplicationAccessible ... 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, correct? 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? Yes 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 (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? 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: 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. 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: http://hg.mozilla.org/mozilla-central/rev/329ff0fcd420 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: 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. 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: 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. 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 Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/802926 Title: firefox starts out inaccessible! (assuming default home page) To manage notifications about this bug go to: https://bugs.launchpad.net/firefox/+bug/802926/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
