Evan Yan Reporter
	Description • 18 years ago

reproduce steps:

1. start firefox and at-poke, use at-poke event log function to log focus and window events;
2. open Customize Encoding dialog by View->Character Encoding->Customize List...
3. in at-poke event log window, we can see only window:deactivate and window:activate event fired, but no focus events fired for the focused list "Available Character Encodings" and the focused list item.

other dialogs also have this bug, like History->Search in History... etc.

I believe this is a regression. I can reproduce it on trunk nightly build 2006-05-12 or later build, but not on nightly build 2005-05-10 or earlier build.

	Evan Yan Reporter
	Comment 1 • 18 years ago

event log by at-poke:

generic event 'focus:' A|co|ac:menu item:Customize List...:(0) (0)
window event 'window:deactivate' (0) (0) on A|co:frame:Google - Minefield: with title 'Google - Minefield'
window event 'window:activate' (0) (0) on A|co:frame:Customize Character Encoding: with title 'Customize Character Encoding'

	Evan Yan Reporter
	Comment 2 • 18 years ago

I checked out code by date and tested them.
the investigation result shows that the regression took place from 10:00 am to 11:00 am on 2006-05-10(time on Bonsai). It seems the big patch for bug 326273 caused this bug. 

Darin, could help to take a look on this?

	Darin Fisher Assignee
	Comment 3 • 18 years ago

-> me

	Darin Fisher Assignee
	Comment 4 • 18 years ago

Where can I get at-poke?

	Evan Yan Reporter
	Comment 5 • 18 years ago

(In reply to comment #4)
> Where can I get at-poke?
> 

Thank you for taking this bug.
You can check out at-poke from gnome cvs and build it. After at-poke started, check the "Log events" checkbox on the bottom, a event listening window will pop up.
Another method to view the events is to run "at-spi/test/event-listener-test". at-spi also can be get from gnome cvs.

Please make sure accessibility enabled when firefox run. It can be done by adding GNOME_ACCESSIBILITY=1 before the command, like "GNOME_ACCESSIBILITY=1 ./firefox".

	parente
	Comment 6 • 18 years ago

Confirmed this bug in Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20060614 Minefield/3.0a1 when GTK_MODULES is set to nothing to avoid Bug #339554.

	Ginn Chen
	Comment 7 • 18 years ago

I think bug 341463 may impact this one.

	Darin Fisher Assignee
	Comment 8 • 18 years ago

If someone has time to help me track down the cause of this bug and fix the problem, I would greatly appreciate it.

	Aaron Leventhal
	Comment 9 • 18 years ago

Evan & Darin, you are both asking for help on this. Can you work together to fix it?

	Evan Yan Reporter
	Comment 10 • 18 years ago

sorry for delay on this, I'll work on this soon.

	Evan Yan Reporter
	Comment 11 • 18 years ago

*** Bug 339191 has been marked as a duplicate of this bug. ***

	Evan Yan Reporter
	Comment 12 • 18 years ago

I did investigation on 4 builds.
(A) build of 2006-05-10 10:00 (before the big patch of bug 326273 checkin);
(B) build of 2006-05-10 11:00 (the patch just checked in)
(C) build of 2006-05-10 17:00 (following patch checked in)
(D) lastest trunk build.
(all the time are Bonsai time)

I tested on menu->Edit->preference dialog. 
when click the menu item 'preference', the preference dialog open, 'focus' event is expected to be fired for the focused image button, whose role is 'radiogroup' in a11y. 

on build A:
nsXULElement::SetFocus() will be called for 'radiogroup'. After event dispatching, we get to nsEventListenerManager::HandleEventSubType(), it will call aListener->HandleEvent(aDOMEvent). The listeners are nsRootAccessible and nsXBLEventHandler. nsRootAccessible::HandleEvent() runs finally for the 'focus' event for the 'radiogroup'. Then 'focus' event will be fired for AT-tools.

on build B:
nsXULElement::SetFocus() is never called while the dialog open.

on build C & D:
nsXULElement::SetFocus() will be called twice for 'radiogroup'. At the first time, it get into nsEventListenerManager::HandleEventSubType(), and the listeners are nsXBLEventHandler but no nsRootAccessible. At the second time, it never reach nsEventListenerManager::HandleEventSubType().

Darin, do you have any idea about which change could make these differences?

	Wayne Mery (:wsmwk)
	Comment 13 • 18 years ago

(In reply to comment #7)
> I think bug 341463 may impact this one.

It's interesting that patch currently in bug 220900 addresses the description of this bug.


Evan in comment #12:
> I did investigation on 4 builds.
> (A) build of 2006-05-10 10:00 (before the big patch of bug 326273 checkin);
> (B) build of 2006-05-10 11:00 (the patch just checked in)
> (C) build of 2006-05-10 17:00 (following patch checked in)
> (D) lastest trunk build.
> (all the time are Bonsai time)
> 
> I tested on menu->Edit->preference dialog. 
> when click the menu item 'preference', the preference dialog open, 'focus'
> event is expected to be fired for the focused image button, whose role is
> 'radiogroup' in a11y. 
> 
> on build A:
> nsXULElement::SetFocus() will be called for 'radiogroup'. After event
> dispatching, we get to nsEventListenerManager::HandleEventSubType(), it will
> call aListener->HandleEvent(aDOMEvent). The listeners are nsRootAccessible and
> nsXBLEventHandler. nsRootAccessible::HandleEvent() runs finally for the 'focus'
> event for the 'radiogroup'. Then 'focus' event will be fired for AT-tools.
> 
> on build B:
> nsXULElement::SetFocus() is never called while the dialog open.
> 
> on build C & D:
> nsXULElement::SetFocus() will be called twice for 'radiogroup'. At the first
> time, it get into nsEventListenerManager::HandleEventSubType(), and the
> listeners are nsXBLEventHandler but no nsRootAccessible. At the second time, it
> never reach nsEventListenerManager::HandleEventSubType().
> 
> Darin, do you have any idea about which change could make these differences?

Bug 355312 appears in the same regression range - the patch in bug 220900 fixes 355312 for me.  I haven't figured out the relationship of Bug 355312 (and bug 220900) to the checkins of bug 326273.  Have you?  

	Ginn Chen
	Comment 14 • 18 years ago

(In reply to comment #13)
> (In reply to comment #7)
> > I think bug 341463 may impact this one.
> 
> It's interesting that patch currently in bug 220900 addresses the description
> of this bug.
> 
> Bug 355312 appears in the same regression range - the patch in bug 220900 fixes
> 355312 for me.  I haven't figured out the relationship of Bug 355312 (and bug
> 220900) to the checkins of bug 326273.  Have you?  
> 

I don't believe patch in bug 220900 can address this bug since the patch is for Windows only.

	Wayne Mery (:wsmwk)
	Comment 15 • 18 years ago

(In reply to comment #14) 
> I don't believe patch in bug 220900 can address this bug since the patch is for
> Windows only.

correct of course - but it is the simarities, including the timing, that are interesting, not the differences

	Ginn Chen
	Comment 16 • 18 years ago

(In reply to comment #15)
> (In reply to comment #14) 
> > I don't believe patch in bug 220900 can address this bug since the patch is for
> > Windows only.
> 
> correct of course - but it is the simarities, including the timing, that are
> interesting, not the differences
> 
Thanks for point it out!
I'll take a look when I've time.

	Evan Yan Reporter
	Comment 17 • 18 years ago

this bug is not reproducable anymore, even on September's nightly build. close it.

Wayne, thanks for raising this up.