Closed Bug 382007 Opened 17 years ago Closed 13 years ago

Focus events inconsistent during tab browsing

Categories

(Core :: Disability Access APIs, defect)

x86
Linux
defect
Not set
normal

Tracking

()

VERIFIED WORKSFORME

People

(Reporter: scott, Unassigned)

References

(Blocks 2 open bugs)

Details

(Keywords: access)

Attachments

(2 files)

When a control has focus in page 1 (forms.html) and you tab browse to page 2 (tables.html) which has focus on the doc frame (probably anywhere for page 2) you receive the following focus events as seen by accerciser:

1) focus(0, 0, None)
	source: [entry | ]
	application: [application | Minefield]
2) object:state-changed:focused(1, 0, None)
	source: [entry | ]
	application: [application | Minefield]
3) focus(0, 0, None)
	source: [document frame | Forms]
	application: [application | Minefield]
4) object:state-changed:focused(1, 0, None)
	source: [document frame | Forms]
	application: [application | Minefield]
5) focus(0, 0, None)
	source: [document frame | Tables]
	application: [application | Minefield]
6) object:state-changed:focused(1, 0, None)
	source: [document frame | Tables]
	application: [application | Minefield]

I would expect not to see focus on the doc frame from the page I am leaving (forms.html) when a control has focus.  Events 3 and 4 should not occur.  I don't know when this change occurred but it has deviated from the events laid out in http://live.gnome.org/LSR/FocusEvents
Blocks: xula11y
Keywords: access, sec508
Further testing shows that this problem does not occur for all controls.  I have seen this problem for multiline textboxes, and single and multiselection lists.  The problem does not exist for single line textboxes, buttons, check boxes, and radio buttons.
This is caused by this.mCurrentBrowser.focusedElement.blur(); from bug 175893
That line also causes bug 323805 and bug 323806.
Depends on: 367806
Joanie, is this something we need to fix for Orca support of Firefox 3?
Aaron, I can't reproduce the bug which makes it hard to know what the impact would be on Orca.

Scott, can you still reproduce it?
I ran the same test that I ran back in May.  Although the results are different, they still show a problem.  The following are two sets of events looking only at focus: and object:state-changed events.  The first set of events is when the focus is on the multiline textbox in page 1.  The second set of events is when the focus in on a single line textbox in page 1.  In both cases the focus is on the doc frame of page 2.

Multiline textbox:
focus:(0, 0, None)
	source: [document frame | Forms]
	application: [application | Minefield]
object:state-changed:focused(1, 0, None)
	source: [document frame | Forms]
	application: [application | Minefield]
focus:(0, 0, None)
	source: [document frame | Tables]
	application: [application | Minefield]
object:state-changed:focused(1, 0, None)
	source: [document frame | Tables]
	application: [application | Minefield]
object:state-changed:active(0, 0, None)
	source: [frame | Tables - Minefield]
	application: [application | Minefield]

Single line textbox:
focus:(0, 0, None)
	source: [document frame | Tables]
	application: [application | Minefield]
object:state-changed:focused(1, 0, None)
	source: [document frame | Tables]
	application: [application | Minefield]

Once again, I would not expect to see the focus events on the doc frame of page 1 as seen in the multiline textbox.

I will study the impact this has on Orca and report back later.
Attached file test page 1
forms.html test page
Attached file second test page
Nothing special about this test page.  Attached for completeness.  I believe you can use any page here just as long at focus is on the doc frame.
My tests show that Orca is not affected by this problem.
Mass un-assigning bugs assigned to Aaron.
Assignee: aaronleventhal → nobody
Could you check if this valid still?
No. Now we only get focus on the document frame of the second tab when activating tab 2, and the previously focused element in doc 1 when activating tab 1. So probably "works for me"
ok, great, thank you. worksforme per comment 11.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → WORKSFORME
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.