Closed Bug 329849 Opened 15 years ago Closed 15 years ago

repeat refreshing impacting tabbing

Categories

(Core Graveyard :: XForms, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: aaronr, Unassigned)

References

Details

(Keywords: fixed1.8.0.5, fixed1.8.1)

Attachments

(1 file)

1.40 KB, application/xhtml+xml
Details
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.
Attached file 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.
Blocks: 331452
No longer blocks: 331452
Depends on: 331452
Assignee: aaronr → xforms
This was fixed by bug 331452. There are still an issue when changing the nodeset, as noted in comment 2.
Status: NEW → RESOLVED
Closed: 15 years ago
Keywords: fixed1.8.1
Hardware: PC → All
Resolution: --- → FIXED
Summary: repeat refreshing impacting tabbing, anonymous content → repeat refreshing impacting tabbing
Whiteboard: xf-to-branch
Blocks: 339586
(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.
Keywords: fixed1.8.0.5
Whiteboard: xf-to-branch
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.