82183 - Not catching focus events on first focus in MFCEmbed

Status: VERIFIED FIXED

(Core :: XUL, defect)

Description

[John Gaunt (redfive)]

nsRootAccessible is set up as a focus listener using capture. The first time
focus is given to the mfcembed program by clicking on a widget, in particular a
form widget ( textfield, checkbox etc... ) nsRootAccessible should catch an
event for that widget. However we are only seeing an event with the target of
nsHTMLDocument come through and no otheres.

This occurs *only* the first time the window is given focus such as:
- after startup, the first click on a form widget
- launching a new window ( using ctrl-n ) and then clicking in the new window as
above
-

These behaviors don't show the problem ( work as expected )
- subsequent ( after the first ) clicks on form widgets
- alt-tabbing away and back, then clicking on form widgets
- minimizing and restoring then clicking on form widgets

The widget still seems to get the messages, but for some reason it never gets to
nsRootAccessible. Checkboxes still check and text areas get focus and start
their carets.

Comment 1

[saari (gone)]

Well, I walked through initial focus on my build, and it looked okay. Where is
this listener of yours?

Comment 2

[John Gaunt (redfive)]

mozilla/accessible/src/nsRootAccessible.cpp is the focus listener that isn't
getting called on the first click.

to reproduce:

1) In order to execute the accessible code you must install the MSAA SDK first (
available from microsoft.com/enable/msaa/download.htm ).
2)Start the Event Watcher tool and then fire up the browser. This will cause the
accessiblity code to be loaded.
3)Put a breakpoint in the nsRootAccessible::Focus() method.
4)Then go to a page with form widgets like
mozilla/webshell/tests/viewer/samples/test8.html and click on a widget -- you
may have to set as home page and test that way.
5)When you click on the widget you will see a focus event come through for the
htmldocument, but not for the widget. But once the document has been focused,
the events that come through are for the widgets.

What's really baffling is that the widget gets the focus. Checkboxes check,
radio buttons check and text fields get focus and you can type in them.

Comment 3

[saari (gone)]

There are a couple bugs here, and John has a patch for one of them in his tree.
They're depending on the target of the focus event, and that doesn't seem to be
right. Need to ask joki where the original target is being set.

Comment 4

[John Gaunt (redfive)]

Looks like the combination of fixes for bug 83220 and bug 81688 fix this as
well. my guess is it is the 83220 fix exclusively, but they are both in my tree.
you might talk with hyatt at some point about 83220 since he is moving a
CheckForFocus call into his nsPresShell::UnsupressPainting code ( i think that
is where it is moving to ).

Comment 5

[John Gaunt (redfive)]

Fixed in accessibility branch: Accessible_052901_Branch4

Comment 6

[Peter Trudelle]

->jgaunt

Comment 7

[John Gaunt (redfive)]

checked in friday 29th to the trunk. letting it bake before pushing for branch (
0.9.2 ) checkin.

Comment 8

[lchiang]

adding vtrunk keyword to indicate the bug has been fixed on the trunk.  Bug left
open for tracking checkin to branch (nsbranch) when appropriate.

Once bug has been fixed on the branch also, pls remove vtrunk keyword.

Comment 9

[John Gaunt (redfive)]

checked in on 0.9.2 branch on wed 4 july.

Comment 10

[Michael Dunn]

David, I am think you might be the best person to verify this bug. 

Comment 11

[David Epstein]

Dharma, could you verify this? It involves using accessibility methods.

Comment 12

[dsirnapalli]

-- Works fine. Marking the bug as verified.