Comments are going from bug 345224. ------- Comment #4 From alexander surkov 2006-08-07 21:16 PDT [reply] ------- (In reply to comment #1) > If we should act like comboboxes then I guess focus should be always in input > field, there we should handle navigation keys and forward them into calendar. > If we're typing date into input field then calendar should show typing date. > Right? > AaronLev, am I right? ------- Comment #5 From Aaron Leventhal 2006-08-14 13:47 PDT [reply] ------- Right, the DOM focus events should be on the main datepicker element, but the accessible focus events we fire from nsRootAccessible::HandleEventWithTarget() should be on any child element in the dropdown that becomes active. Your impl could fire a custom DOM event that nsRootAccessible maps to the accessible focus events. Also any time the value in the input field changes you should fire a custom ValueChange DOM event for it. That will cause the nsRootAccessible::HandleEventWithTarget() method to map that to accessible value change events.

(In reply to comment #0) > Right, the DOM focus events should be on the main datepicker element Aaronlev, is it valid per bug 361997? If calendar is complex widget that includes year/month navigation controls and day grid then should focus be in textfield element?

I'd say focus can go inside the calendar as it does now. I think bug bug 361997 can override this.

Marking dublicate of bug 361997.