343443 - output in label in select doesn't work

Status: RESOLVED WONTFIX

(Core Graveyard :: XForms, defect)

Description

[aaronr]

A user gave us a testcase of an itemset containing a label containing an output doesn't work.  It doesn't seem to work in most processors I tried, though it does work in formsPlayer.

The main problem right now seems to be that we aren't cloning the label inside buildItemset like we do in buildItem.  We are just using the label text when creating the html:option.

Comment 1

[aaronr]

Attachment: testcase

Comment 2

[aaronr]

Attachment: testcase 2

Comment 3

[aaronr]

Ok, a couple of issues that need to be fixed, here.

1) need output to tell label that it needs to tell the select/select1 to refresh.  Similar to item->labelRefreshed, except we don't need the label to refresh.  It just needs to call item->labelRefreshed.  Might be best to have all items set a flag on its label so that the label knows that it is an item label.  Then if the output sees its parent is a label that is an item label, then knows to pass the refresh notification up the line.  The other approach is to put a listener on all item labels and if they get a xforms-value-changed event during bubble that isn't targeted at the label, then it knows to do the same thing.  How inefficient is it to have every item label in a select/select1 have a listener Olli?

2) need to get the select/select1 to rebuild its xbl control so that the options are updated.  Probably not as simple as just calling refresh.  Have to track the call sequence of a item->labelRefreshed to see if it takes care of this issue.

We might have to consider, possibly, a closer tie between the item and the html:option in the skinned control.  Is it possible to just update one option in a html:select without having to rebuild the select?  Do options respond well to DOM changes?  I'm just wondering how bad performance could be if we have to build the whole list every time an output in a item label changes.

Comment 4

[Olli Pettay [:smaug][[e-mail]]]

(In reply to comment #3)
> to put a listener on all item labels and if they get a xforms-value-changed
> event during bubble that isn't targeted at the label, then it knows to do the
> same thing.  How inefficient is it to have every item label in a select/select1
> have a listener Olli?

It is not that inefficient,  but I think having a flag in label would be better solution.

I assume this bug happens only with select, not select1?

Comment 5

[alexander :surkov (:asurkov)]

(In reply to comment #3)
> Ok, a couple of issues that need to be fixed, here.
> 
> 1) need output to tell label that it needs to tell the select/select1 to
> refresh.  Similar to item->labelRefreshed, except we don't need the label to
> refresh.  It just needs to call item->labelRefreshed.  Might be best to have
> all items set a flag on its label so that the label knows that it is an item
> label.  Then if the output sees its parent is a label that is an item label,
> then knows to pass the refresh notification up the line.  The other approach is
> to put a listener on all item labels and if they get a xforms-value-changed
> event during bubble that isn't targeted at the label, then it knows to do the
> same thing.  How inefficient is it to have every item label in a select/select1
> have a listener Olli?

We can use other binding for label as a flag. "xforms-value-changed" event doesn't clasp all cases. Probably should we listen mutation events?

Comment 6

[alexander :surkov (:asurkov)]

(In reply to comment #4)

> I assume this bug happens only with select, not select1?
> 

Yes, it's only for select.

Comment 7

[alexander :surkov (:asurkov)]

The bug is related with bug 332081. Thease are two issues of one the same problem. The problem is we copy labels.

Comment 8

[aaronr]

(In reply to comment #6)
> (In reply to comment #4)
> 
> > I assume this bug happens only with select, not select1?
> > 
> 
> Yes, it's only for select.
> 

Nick showed me something similar happening for select1's, but I can't seem to recreate it now on my own.  Hopefully he'll be able to point me in the right direction

Comment 9

[aaronr]

Ugh, ran into a stickler of a problem with my approach.  ContainerNeedsPostRefresh starts refreshing the select, and during that the output will refresh (if I remember right due to widget attachment) which will force the containing label to tell its control (xf:item) that it needs to tell its select to refresh.  But the select is alaready refreshing so the request just gets ignored.  So the select's options aren't updated.  I'm going to have to re-think this.

Comment 10

[J. Cliff Dyer]

Attachment: testcase w/ select1

I'm attaching a test case that demonstrates this bug's behavior within <select1>.

Cheers,
Cliff

Comment 13

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

RIP xforms