360188 - select1 keyboard navigation problems

Status: RESOLVED FIXED

(Core Graveyard :: XForms, defect)

Description

[aaronr]

It is possible to get xf:select1 in such a state that it will not allow keydown or keyup navigation.  It seems to be an issue with replacing/rebuilding the instance the select1 binds to when it contains a xf:itemset.

Comment 1

[aaronr]

Attachment: external instance data

external instance data for the testcase

Comment 2

[aaronr]

Attachment: testcase

Comment 3

[aaronr]

The following appears in the error console:

Error: parent has no properties
Source File: chrome://xforms/content/select1.xml
Line: 354

Comment 4

[aaronr]

The problem is with the rebuild.  At the point of xforms-ready, select1 has a selected item which lives in the itemset.  The rebuild is causing the xf:itemset to remove its old content and repopulate with new xf:items.  And when it does this, then select1 is refreshed, but since the currently selected item (the one itemset removed) already has the correct value, we think we are saving ourselves a lot of work and we just return.  So this._selected will always be the old, removed item.  Any function that then tries to use the DOM based of this selected item will run into troubles since the item no longer lives in the DOM.  That is why we are getting the "parent has no properties" error.

The way to fix this is probably to clear the select/select1's cache of selected value(s) when xf:itemset is refreshed.  That should be safe because anytime this happens, we should force the select/select1 to refresh again.  I'll work on this fix.

Comment 5

[aaronr]

Attachment: testcase2

Getting some bad behavior from select, too.

Comment 6

[aaronr]

(In reply to comment #5)
> Created an attachment (id=255965) [details]
> testcase2
> 
> Getting some bad behavior from select, too.
> 

unrelated problem, but I'll fix it in this patch, too, since the fix is minor.  Problem is that the new removeNativeElm() method had some bugs in it.

Comment 7

[aaronr]

Attachment: patch

I fixed this using the mutation handler that alex put in select1.xml.  If we detect that an item is getting removed, we check to see if it is the currently selected item.  If it is, then we'll null it out so that it isn't remembered when select1 refreshes the next time.

Comment 8

[aaronr]

checked into trunk

Comment 9

[aaronr]

crap, looks like this patch won't work on FF2.  I never see the DOMNodeRemoved handler firing.  Maybe this was fixed by bug 367164, but that never made it into the branches.

Comment 10

[aaronr]

Attachment: patch for 1.8 and 1.8.0

this patch works around the limitation of DOMNodeRemoved not working on the branch.  This approach won't be needed once we do the performance re-write where itemset insertions and deletions of items will be handled much cleaner.

Comment 11

[aaronr]

checked into 1.8 branch on 2007-04-12
checked into 1.8.0 branch on 2007-04-16