Open barnomics opened 8 years ago
@barnomics This seems odd, but I'm curious to see the use case. The underlaying issue is that when you focus the window back, a focus event is triggered on the DOM node that was previously focused. In iron-list, that means that the item should be brought into view whenever the item received focus regardless of where the focus event came from. The click event happens after the focus event, so that's why you see this issue. A workaround:
this.listen(window, 'focus', '_focus');
and then:
_focus: function() {
var focusedItem = this.$.list._focusedItem;
this.$.list._focusedItem = null;
this.async(function() {
this.$.list._focusedItem = focusedItem;
}, 1);
},
Iron-list doesn't add listeners or behavior to window or any node from outside the list itself, so it's very unlikely that this code would be landed directly, but it could expose a public API e.g. renaming _focusedItem -> focusedItem
to achieve this behavior.
I also have a semi-related issue to focusing. My iron-list the elements are expandable. Lets say its a list of 100 items.
5
) at the top of the list 50
). 47
is cut off in the view), item 47
will scrollIntoView ... moving the whole list down a number of pixels.50
never happens because the target has moved from its original position@barnomics I can only reproduce the issue if I move focus outside the window (e.g. I focus the address bar or dev tool as you mentioned in the initial issue) using this demo https://elements.polymer-project.org/bower_components/iron-list/demo/collapse.html. Do you have a jsbin that reproduces the issue?
Description
iron-list focusing and collapsing behaves strangely. It's rather difficult to explain what's going on so I'll just list the steps to reproduce.
Steps to reproduce
Expected outcome
Actual outcome
Browsers Affected