Got this testcase from a user on the newsgroup. Looks like if I have an input inside a repeat with a nodeset the size of two (so the user sees two inputs)and I tab around, the tab goes from the first input to the second very smoothly. However, if I change the value of the first input and hit tab, it DOESN'T go to the second input. It ends up somewhere else (seems like the document). I see that the repeat's refresh method is called which will delete all of the contents of the repeat element and rebuild them. I think that is what is screwing up the focus chain. On 180branch, we actually see a this.parentNode error. Doesn't happen on trunk, but I think that is more of a side effect of Surkov's getControl changes in the XBL. But if we do a setValue in a blur handler and then do other things in the handler interacting with the control, we could ru into other issues. Probably not limited to this testcase.

(In reply to comment #0) > I see that the repeat's refresh method is > called which will delete all of the contents of the repeat element and rebuild > them. I think that is what is screwing up the focus chain. That is possibly what is happening, yes. Hmmm, it will be hard to maintain tab order always... as the refresh might remove the element that we either tab out of, or tab into. Nevertheless we are refreshing too much. Aparently the repeat must depend on the entire nodeset, which is not needed. It should only depend on nodes that could change the nodes shown, not their content. That is, it should only depend on any predicates used. Fixing that would solve many of the usecases. Fixing the general tab-order problem is harder.... if the nodes being shown actually changes because the user changes an input inside the same repeat, I guess it would not be totally unacceptable to keep focus on the same input. That can be done by repeat::refresh() by checking whether it's repeat-index has focus, and if, then reset the focus to it after the refresh.

This was fixed by bug 331452. There are still an issue when changing the nodeset, as noted in comment 2.

(In reply to comment #2) > Fixing the general tab-order problem is harder.... if the nodes being shown > actually changes because the user changes an input inside the same repeat, I > guess it would not be totally unacceptable to keep focus on the same input. > That can be done by repeat::refresh() by checking whether it's repeat-index has > focus, and if, then reset the focus to it after the refresh. > Filed follow up bug 339586 for this.