333464 - filtered select1 in repeat doesn't size correctly

Status: RESOLVED WONTFIX

(Core Graveyard :: XForms, defect)

Description

[Brad Clements]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1

In 0.5RC from 2006-04-09, a form similar to that example from bug 333045 except with the select1 elements inside a repeat demonstrates incorrect sizing.

The 2nd select1 in each repeat template has it's width set incorrectly and "no selected choice" is shown when a new template is added.

Reproducible: Always

Steps to Reproduce:
1. Make a selection in the primary medical condition select1
2. make a selection in the secondary medical condition select1
3. press "add medical condition" trigger.


Actual Results:  
The previously selected secondary medical condition select1 now has incorrect width and doesn't show a value.

Each time a new template is added, all the secondary medical condition select1 elements get the wrong width

Expected Results:  
The previously set select1's should retain their visible selection and width.

I suspect the xforms-value-changed action on the primary-medical-condition select1 is causing this problem. The instance model appears correct, so this seems to be just a display problem.

maybe the 'fixed' select1 sizing code is not paying attention to repeat-index..

Comment 1

[Brad Clements]

Attachment: select1 repeat test case

Here's the test case.

Comment 2

[aaronr]

whoever fixes this bug, please change the NS_ENSURE_STATE(anonContent) in nsXFormsItemSetElement::Refresh to an 'if' test.  It is ok for anonContent to be nsnull if the xbl hasn't attached, yet.  All those warnings in the debug console are distracting :=)

Comment 3

[Allan Beaufour]

Here's a guess at what goes wrong: The repeat refreshing is "not optimal" (bug 331452), and the "unrolled" content is re-created on each refresh. So the select1s are recreated, and probably get an xforms-value-changed because of this, killing the second select1 value because of the event listener on that event.

Comment 4

[Brad Clements]

I don't agree entirely with allan's guess.

the setvalue on the xforms-value-changed action should change the instance. However xforms buddy shows that the instance is correct, even though the 2nd select1 elements in each repeat display no values.

Also, after adding a new template (and seeing the 2nd select1 elements appear to be reset), you can click the down arrow on those the previously set select1 elements and see that there are items in the select and that the correct item is still highlighted.

The select1 width gets reset incorrectly, and the select1 appears to have no selection until you click the down-arrow part of the select1.

Comment 5

[Allan Beaufour]

(In reply to comment #4)
> I don't agree entirely with allan's guess.
> 
> the setvalue on the xforms-value-changed action should change the instance.
> However xforms buddy shows that the instance is correct, even though the 2nd
> select1 elements in each repeat display no values.

Heh. I didn't actually run the form, now I did, and you sure are right. The instance data looks valid.

Eh, it looks like the resize code for the select1 works "globally". As in, it resizes the drop-downbox for all the select1s when one is resized.

Comment 6

[Brad Clements]

Does anyone have any more ideas on this one? Still doesn't work in 0.8.4 on Linux.

I have found some more select1 problems, not in a repeat. I'll try to put together a test case. Basically when loading from an itemset, if the value is empty, then the label for that item doesn't show up when it's selected.

Also have problems where no selected labels are showing up (compact) or none showing up and a 1em wide column (minimal).

Comment 7

[David Bolter [:davidb] (NeedInfo me for attention)]

RIP xforms