repeat refreshing impacting tabbing

RESOLVED FIXED

Status

Core Graveyard
XForms
RESOLVED FIXED
11 years ago
10 months ago

People

(Reporter: aaronr, Unassigned)

Tracking

({fixed1.8.0.5, fixed1.8.1})

Trunk
fixed1.8.0.5, fixed1.8.1
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

1.40 KB, application/xhtml+xml
Details
(Reporter)

Description

11 years ago
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.
(Reporter)

Comment 1

11 years ago
Created attachment 214498 [details]
testcase

Comment 2

11 years ago
(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.

Updated

11 years ago
Blocks: 331452

Updated

11 years ago
No longer blocks: 331452
Depends on: 331452

Updated

11 years ago
Assignee: aaronr → xforms

Comment 3

11 years ago
This was fixed by bug 331452. There are still an issue when changing the nodeset, as noted in comment 2.
Status: NEW → RESOLVED
Last Resolved: 11 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

Updated

11 years ago
Blocks: 339586

Comment 4

11 years ago
(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.

Updated

11 years ago
Keywords: fixed1.8.0.5

Updated

11 years ago
Whiteboard: xf-to-branch
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.