Skip to content
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

Open
toddpi314 opened this issue Nov 9, 2015 · 5 comments
Open

ListView and initial focus for Custom Item Templates #1546

toddpi314 opened this issue Nov 9, 2015 · 5 comments
Milestone

Comments

@toddpi314
Copy link

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:

if ((entity.type === _UI.ObjectType.groupHeader && event.target === element) ||
(entity.type === _UI.ObjectType.item && event.target.parentNode === element)) {

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 the win-focusedoutline element appended to the respective win-item.

Looks like a bug.

@toddpi314 toddpi314 changed the title ListView and initial focus via TabManager ListView and initial focus for Custom Item Templates Nov 9, 2015
@toddpi314
Copy link
Author

We see the behavior appear correct when we comment out this line:

if (this._keyboardFocusInbound || this._selection._keyboardFocused()) {

@toddpi314
Copy link
Author

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...

@toddpi314
Copy link
Author

Based on the code, it looks like a check for _hasKeyboardFocus might be appropriate.

@jdalton jdalton added this to the Future milestone Nov 12, 2015
@humale
Copy link
Contributor

humale commented May 23, 2016

Hi @toddpi314. I was wondering if you could make a PR for the workaround that you've proposed.

@staxmanade
Copy link

staxmanade commented Nov 23, 2016

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);
                                }
                            }

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants