-
Notifications
You must be signed in to change notification settings - Fork 473
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ListView and initial focus for Custom Item Templates #1546
Comments
We see the behavior appear correct when we comment out this line: winjs/src/js/WinJS/Controls/ListView.js Line 2809 in a59be9d
|
Confirmed that the issue does not occur when using the 'tab' keystroke to 'enter' focus into the List-View. Looks like we just need a condition to detect when focus-In comes from the FocusXY logic... |
Based on the code, it looks like a check for _hasKeyboardFocus might be appropriate. |
Hi @toddpi314. I was wondering if you could make a PR for the workaround that you've proposed. |
Doing as @toddpi314 suggested is also working for me. Can't speak to the rammifications of other use-cases...) but it's working well so far. // In the old layouts, index will be -1 if a group header got focus
if (entity.index !== _Constants._INVALID_INDEX) {
- if (this._keyboardFocusInbound || this._selection._keyboardFocused()) {
+ {
if ((entity.type === _UI.ObjectType.groupHeader && event.target === element) ||
(entity.type === _UI.ObjectType.item && event.target.parentNode === element)) {
// For items we check the parentNode because the srcElement is win-item and element is win-itembox,
// for header, they should both be the win-groupheader
this._drawFocusRectangle(element);
}
} |
We are seeing that the first item in our ListViews are not getting the focus container when using the FocusXY navigation to do the focus in.
It appears our bound items are not qualifying somewhere here:
winjs/src/js/WinJS/Controls/ListView.js
Lines 2810 to 2811 in a59be9d
The first list item does get set on the document.activeElement, but we don't see the list-view respond with either the
win-focused
class or thewin-focusedoutline
element appended to the respective win-item.Looks like a bug.
The text was updated successfully, but these errors were encountered: