Last Comment Bug 329849 - repeat refreshing impacting tabbing
: repeat refreshing impacting tabbing
Status: RESOLVED FIXED
: fixed1.8.0.5, fixed1.8.1
Product: Core
Classification: Components
Component: XForms (show other bugs)
: Trunk
: All All
: -- normal (vote)
: ---
Assigned To: xforms
: Stephen Pride
Mentors:
Depends on: 331452
Blocks: 339586
  Show dependency treegraph
 
Reported: 2006-03-08 16:17 PST by aaronr
Modified: 2006-06-06 07:00 PDT (History)
4 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
testcase (1.40 KB, application/xhtml+xml)
2006-03-08 16:24 PST, aaronr
no flags Details

Description aaronr 2006-03-08 16:17:53 PST
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.
Comment 1 aaronr 2006-03-08 16:24:58 PST
Created attachment 214498 [details]
testcase
Comment 2 Allan Beaufour 2006-03-11 09:09:56 PST
(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.
Comment 3 Allan Beaufour 2006-05-29 07:20:25 PDT
This was fixed by bug 331452. There are still an issue when changing the nodeset, as noted in comment 2.
Comment 4 Allan Beaufour 2006-05-29 07:22:44 PDT
(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.

Note You need to log in before you can comment on or make changes to this bug.