The highlighting does not return to the actual recipient edit field when the auto-complete list is closed

This sounds like a potentially blocking issue. Why isn't this the case?

The highlighting does not return to the actual recipient edit field when the auto-complete list is closed

This sounds like a potentially blocking issue. Why isn't this the case?

The auto-complete list and its items are not focusable and never receive system focus. The only events the NVDAObject of the AutoCompleteListItem receives, are the event_stateChange and event_selection events when navigating through the list.
There seems to be no event fired on the list items when the list is closed, either through selecting an item, or closing the list by pressing escape.

By setting the NVDA-internal focus and nagivator object to these list items, the Highlighter highlights them correctly. That is what I am doing so far.

The edit field themselves receive event_valueChange events when a item from the list is confirmed with enter and inserted into the edit field, or when typing in the edit field. By providing a custom class for these edit fields, it is possible to transfer focus back to them when their value changes.
This works for all cases, except when the list is closed by dismissing it (pressing escape). In that case the focus would stay on the (hidden) list, until the edit field value changes or the focus is set to a different element.

If you can think of a way to direct focus back to the edit field when the list is dismissed, I would be more than happy to try to implement it.

... except when the list is closed by dismissing it (pressing escape). In that case the focus would stay on the (hidden) list, until the edit field value changes or the focus is set to a different element.

How are you validating what events are fired? With MSAA/Events debugging categories?
I would expect the hide event when the auto complete list disappears.

How are you validating what events are fired? With MSAA/Events debugging categories? I would expect the hide event when the auto complete list disappears.

Currently I am overriding all event_* methods defined by the NVDAObject class in the AutoCompleteListItem class to log which events are fired. This does not have a hide event method though.

I know that the winEvent EVENT_OBJECT_HIDE exists. Is there a way to retrieve it in classes that inherit from NVDAObject?

1. You can just define event_hide on the object class.
2. The proper way to inspect events would be enabling debug logging and explicitly opt into the MSAA/Events categories in NVDA's advanced settings. This gives you all the events fired.

It would make sense to do something similar to what happens in other auto-complete lists.

Looking at the start menu, when I type in the search field and then press arrows, the focus and nav object highlighters move between suggestions. Pressing NVDA+numpad5 reports the current suggestion, but pressing NVDA+tab reports the edit field. So the reported focus with NVDA+tab and its highlighted position are somewhat inconsistent.

On the opposite, the experience with Firefoxaddress bar seems similar to what is described in this PR.

In any case, the fact that the highlighter does not turn back to the edit field when the suggestions are dismissed is problematic IMO.

I have spent quite some time investigating the events fired on the auto-complete list and its items, as well as on the parent elements of the list. Unfortunately, I could not find any event, like hide or similar, to detect when the list is closed.

The only solution that I could think of, that works, is to detect the escape keypress itself using a script on the edit fields. When detecting the escape keypress there and directing the focus and navigator object back it it, everything seems to work as intended.

I have also looked at the general Highlighter behavior on the Windows start menu. There it seems that only the navigator object is set to the selected item while the focus object remains on the edit field. If this is the desired behavior, I can adjust my code to also only set the navigator object.

The only solution that I could think of, that works, is to detect the escape keypress itself using a script on the edit fields. When detecting the escape keypress there and directing the focus and navigator object back it it, everything seems to work as intended.

At first glance, seems nice to me. Are there drawbacks to this solution? Or uncovered use cases / workflows?

I have also looked at the general Highlighter behavior on the Windows start menu. There it seems that only the navigator object is set to the selected item while the focus object remains on the edit field. If this is the desired behavior, I can adjust my code to also only set the navigator object.

Here it should be discussed and agreed to know which is the desired behaviour? Start menu behaviour or Firefox address bar? Then you can change your code according to what is chosen.

... everything seems to work as intended.

At first glance, seems nice to me. Are there drawbacks to this solution? Or uncovered use cases / workflows?

None that I can currently think of.

... everything seems to work as intended.

At first glance, seems nice to me. Are there drawbacks to this solution? Or uncovered use cases / workflows?

None that I can currently think of.

@Nerlant a few that spring to mind:

• What about when the user clicks outside the autocomplete list? Does that cause the autocomplete list to disappear? If so, does the highlight rectangle move appropriately?
• What about when the user types text that initially returns matches, but when they continue typing suggestions are no-longer available? E.G. I type "Jane" and Outlook suggests "Jane Doe" and "Jane Blogs", but then I keep typing " St" and there's no-one of that description in my address book, so no autocompletions are offered.
• What about when the user presses enter or clicks on a suggestion to accept it?

• What about when the user clicks outside the autocomplete list? Does that cause the autocomplete list to disappear? If so, does the highlight rectangle move appropriately?

When the user clicks on another element that can have focus, the highlight rectangle moves to the element with focus.

• What about when the user types text that initially returns matches, but when they continue typing suggestions are no-longer available? E.G. I type "Jane" and Outlook suggests "Jane Doe" and "Jane Blogs", but then I keep typing " St" and there's no-one of that description in my address book, so no autocompletions are offered.
• What about when the user presses enter or clicks on a suggestion to accept it?

As soon as the value of the contact edit field changes, the focus is set back to it. This applies both to entering text in the edit field and to accepting suggestions.

• What about when the user clicks outside the autocomplete list? Does that cause the autocomplete list to disappear? If so, does the highlight rectangle move appropriately?

When the user clicks on another element that can have focus, the highlight rectangle moves to the element with focus.

Even if this focusable element is the field where they have typed the first characters?

In any case, even if there are such corner cases, in my opinion the benefit is higher than the little bugs introduced by the corner cases (if any).

When the user clicks on another element that can have focus, the highlight rectangle moves to the element with focus.

Even if this focusable element is the field where they have typed the first characters?

When clicking into the edit field for which the auto-complete list is currently opened, the list closes for a short moment before re-opening. The highlighter rectangle then resets to the first entry of the auto-complete list, which is automatically selected by Outlook.

Please add a changelog entry under bug fixes

@Nerlant - can you please resolve merge conflicts? or grant me permission to push to your branch

@Nerlant - can you please resolve merge conflicts? or grant me permission to push to your branch

I will resolve them and request a review from you again