[JENKINS-43326] Invalid (randomly) form submission JSON from optional blocks ("groupNode") #2858
Conversation
…eRef) is somehow getting reset after the fact The groupingNode property on the element is getting set to true via the "TR.row-set-end" behaviour, but *sometimes* is lost from the element by the time the form is submitted. A listener/timer is cutting in async from somewhere it seems hence the groupingNode prop is being lost
.. and it was ... suggesting something is createating the element from scratch => losing the groupingNode property
… attribute. The attribute values do get copied i.e. not lost by whatever is modifying the element.
tfennelly
added
the
on-hold
tfennelly
changed the title
|
Looks like the form-element-path-plugin would be effected by this change. Maybe we need to continue setting the element property for a while. |
| @@ -1339,7 +1339,7 @@ function replaceDescription() { | |||
| * and attached under the element identified by the specified id. | |||
| */ | |||
| function applyNameRef(s,e,id) { | |||
| $(id).groupingNode = true; | |||
There was a problem hiding this comment.
So I have seen the exact same random recreation of elements in other code and my fix was to move storage to a different location. In my case I couldn't stash in an attribute because YUI was doing other changes to the dom.
My interpretation was that there is a hashmap like data structure and hence the hash-order is non-predictable leading to some of the time getting the element recreated
|
@Vlatombe @olivergondza Can one of you comment on whether this will break form-element-path-plugin as Tom fears? |
|
Unless you patch |
|
🐛 When I tested this, the descriptor radio boxes didn't show up. I think I have a reproduction of the actual issue and am working on filing it. |
|
Hi @tfennelly The last feedback on this PR is that it's broken and that was on 2017. Are you planning to work on this? If not, are you OK with closing the PR? it is consuming CI cicles. Thanks! |
|
This seems abandoned for two years now based on the comment, so closing it. It seems like a useful change though, and it would be nice if you would resubmit it for review. |
See JENKINS-43326.
@recampbell @varmenise
Guys, if you take a look at the commits you'll see the steps I went through.
TL;DR: some piece of async code is resetting some
behaviours.jsadded properties on the optionalBlock element (actually looks as though the element is being recreated - didn't manage to find what code is doing this), causing the form submission value to be screwed when the form is being submitted (because the form submission code does not think the checkbox is relating to a "groupNode").To fix, I changed the
behaviour.jscode and form submission code to set and get a DOM attribute value instead. This seems to work from the testing I've done i.e. I could see that thegroupNodeproperty on theewas being lost, while the attribute value was not being lost.Of course, needs more testing and checking etc.