output in label in select doesn't work

RESOLVED WONTFIX

Status

Core Graveyard
XForms
RESOLVED WONTFIX
11 years ago
11 months ago

People

(Reporter: aaronr, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(3 attachments)

1.66 KB, application/xhtml+xml
Details
1.23 KB, application/xhtml+xml
Details
2.54 KB, application/xml
Details
(Reporter)

Description

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

Comment 1

11 years ago
Created attachment 227930 [details]
testcase
(Reporter)

Comment 2

11 years ago
Created attachment 227934 [details]
testcase 2
(Reporter)

Comment 3

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

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

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

11 years ago
(In reply to comment #4)

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

Yes, it's only for select.

Comment 7

11 years ago
The bug is related with bug 332081. Thease are two issues of one the same problem. The problem is we copy labels.
(Reporter)

Comment 8

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

Comment 9

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

Updated

11 years ago
Blocks: 326372

Comment 10

10 years ago
Created attachment 284489 [details]
testcase w/ select1

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

Cheers,
Cliff
(Reporter)

Updated

10 years ago
Duplicate of this bug: 399419
(Reporter)

Updated

9 years ago
Duplicate of this bug: 437012
RIP xforms
Status: NEW → RESOLVED
Last Resolved: a year ago
Resolution: --- → WONTFIX
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.