512058 - Can't set focus to designMode document via accessibility APIs

Status: VERIFIED FIXED

(Core :: Disability Access APIs, defect, P2)

Description

[James Teh [:Jamie]]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a1pre) Gecko/20090821 Minefield/3.7a1pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a1pre) Gecko/20090821 Minefield/3.7a1pre

When designMode is used within an iframe to embed an editable document, it is not possible to set focus to the editable document using accessibility APIs.

Reproducible: Always

Steps to Reproduce:
1. Open the attached test case.
2. Locate the accessible for the editable document.
3. Try to set focus to it using accessibility APIs. For MSAA, this is done using accSelect with SELFLAG_TAKEFOCUS.
Actual Results:  
The editable document does not receive focus.

Expected Results:  
The editable document should receive focus.

Setting focus to the iframe containing the editable (designMode) document does cause the editable document to receive focus. However, setting focus to the editable document should also cause it to receive focus.

Comment 1

[James Teh [:Jamie]]

Attachment: Test case.

Comment 2

[James Teh [:Jamie]]

This bug is not present in Firefox 3.5.2.

Comment 3

[Marco Zehe (:MarcoZ)]

Suspected regression from bug 178324 (the big focus refactor). This, along with bug 512059, prevent NVDA from better supporting design mode documents such as when composing mail in GMail's web interface, thus preventing them from reacing a Mozilla Foundation grant goal. Requesting blocking.

Comment 4

[David Bolter [:davidb] (NeedInfo me for attention)]

Attachment: exploratory WIP

This seems to fix the bug (confirmed via accprobe), but it is pretty blunt surgery. Some things I'd like confirmation on:

1. Does this bug also affect linux?
2. Does this patch fix this bug?
3. Does my patch break anything (would have broken LSR, does it break Orca)?

Comment 5

[David Bolter [:davidb] (NeedInfo me for attention)]

Note we have some fairly delicate focus code; makes me nervous. Also Neil has a note in our code that we shouldn't cache the last focused node... we need to sort this out.

Comment 6

[David Bolter [:davidb] (NeedInfo me for attention)]

Uhm, last two comments (and attachment) were mean't for bug 512059 but good to know if the fix is good here too.

Comment 7

[David Bolter [:davidb] (NeedInfo me for attention)]

This sems to be fixed via https://bug512561.bugzilla.mozilla.org/attachment.cgi?id=402856

Leaving open until that passes review and lands.

Comment 8

[David Bolter [:davidb] (NeedInfo me for attention)]

Fixed via patch on bug 512561.

Comment 9

[Marco Zehe (:MarcoZ)]

I'm having trouble verifying this bug using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a1pre) Gecko/20090929 Minefield/3.7a1pre (.NET CLR 3.5.30729), where bug 512561 is indeed verified fixed. Jamie, can you take a look at this build and see if it fixes the bug for you?

Comment 10

[David Bolter [:davidb] (NeedInfo me for attention)]

Let's reopen. It might need the patch from bug 512059 as well.

Comment 11

[David Bolter [:davidb] (NeedInfo me for attention)]

... since although focus should go to the designMode document, screen readers will not be notified without the event firing (bug 512509) -- so hard to verify I imagine.

Comment 12

[David Bolter [:davidb] (NeedInfo me for attention)]

OK seems to work for me with patch from bug 512561. I'm testing with Inspect32. I have inspect set to follow only focus, I move focus to the first button, then go to the next sibling (editable text), then to the next sibling (iframe), then the first child (document), then press the focus tool button. I then click on the browser window title bar to bring focus to the browser and can visually confirm the blinking caret in the editable iframe document.

Reverting the patch from bug 512561, I can't get it to work. So seems to be fixed by that patch.

Comment 13

[David Bolter [:davidb] (NeedInfo me for attention)]

OK after Marco told me how to use accprobe to do the select I was able to confirm using accprobe as well. Hopefully we can get this verified thanks. Re-closing as fixed.

Comment 14

[James Teh [:Jamie]]

Verified fixed in: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a1pre) Gecko/20090929 Minefield/3.7a1pre. As David noted, this needs bug 512059 to be truly useful. However, I can verify that the issue covered by this bug is fixed; the focused state is set on the editable document and typing results in the characters being added to it.

Comment 15

[David Bolter [:davidb] (NeedInfo me for attention)]

Thanks Jamie, marking 1.9.2 beta fixed.

Comment 16

[Marco Zehe (:MarcoZ)]

Verified in Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2b1pre) Gecko/20090930 Namoroka/3.6b1pre (.NET CLR 3.5.30729)

Comment 17

[David Bolter [:davidb] (NeedInfo me for attention)]

Test added:
http://hg.mozilla.org/mozilla-central/rev/073164ba54ce

Comment 18

[David Bolter [:davidb] (NeedInfo me for attention)]

For the record, comment 7 was backed out immediately and the related tests for this bug landed as follows:
192 landing was: http://hg.mozilla.org/releases/mozilla-1.9.2/rev/2a23df8cc57a
central landing was: http://hg.mozilla.org/mozilla-central/rev/9a82c2bc0687