Last Comment Bug 343443 - output in label in select doesn't work
: output in label in select doesn't work
Status: RESOLVED WONTFIX
:
Product: Core
Classification: Components
Component: XForms (show other bugs)
: Trunk
: x86 All
: -- normal with 3 votes (vote)
: ---
Assigned To: xforms
: Stephen Pride
Mentors:
: 399419 437012 (view as bug list)
Depends on:
Blocks: 326372
  Show dependency treegraph
 
Reported: 2006-07-02 22:49 PDT by aaronr
Modified: 2016-02-04 12:21 PST (History)
4 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
testcase (1.66 KB, application/xhtml+xml)
2006-07-02 22:56 PDT, aaronr
no flags Details
testcase 2 (1.23 KB, application/xhtml+xml)
2006-07-02 23:29 PDT, aaronr
no flags Details
testcase w/ select1 (2.54 KB, application/xml)
2007-10-11 09:44 PDT, J. Cliff Dyer
no flags Details

Description aaronr 2006-07-02 22:49:43 PDT
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 2006-07-02 22:56:18 PDT
Created attachment 227930 [details]
testcase
Comment 2 aaronr 2006-07-02 23:29:57 PDT
Created attachment 227934 [details]
testcase 2
Comment 3 aaronr 2006-07-03 00:52:58 PDT
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] (high review load, please consider other reviewers) 2006-07-03 01:16:22 PDT
(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 2006-07-04 01:34:40 PDT
(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 2006-07-04 19:35:36 PDT
(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 2006-07-04 19:39:03 PDT
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 2006-07-05 12:32:23 PDT
(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 2006-07-18 16:17:20 PDT
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 2007-10-11 09:44:42 PDT
Created attachment 284489 [details]
testcase w/ select1

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

Cheers,
Cliff
Comment 11 aaronr 2007-10-11 11:16:19 PDT
*** Bug 399419 has been marked as a duplicate of this bug. ***
Comment 12 aaronr 2008-06-03 11:07:03 PDT
*** Bug 437012 has been marked as a duplicate of this bug. ***
Comment 13 David Bolter [:davidb] 2016-02-04 12:21:47 PST
RIP xforms

Note You need to log in before you can comment on or make changes to this bug.