Login  Register

Bug: Old field value persists after change, gets used in default macro call

Posted by DavidJCobb on Jul 22, 2012; 11:26pm
URL: https://support.nabble.com/Bug-Old-field-value-persists-after-change-gets-used-in-default-macro-call-tp7580796.html

There is currently a bug that breaks our Quick Reply feature. If someone uses the Quick Reply form without first anchoring it to a post, then when they submit, their post is added directly to the forum index (rather than as a reply to the topic they were in).

That bug appears to stem from a Nabble-side change, where the "node" field in <n.form> calls is now set to the ID of the root node (rather than the ID of the page node, which is what I think it used to be). However, that's just a website bug. A bug in NAML itself arises when we try to fix the website bug... I put a call like the following directly before the "form" macro that contains the problematic field:

<n.node_field.set_value value="[n.page_node.id/]"/>

However, the <n.node_field.hidden/> call inside of the "form" macro still wrote out the old value. So I put this SPAN inside the "form" call, like so, so I could see what was going on:

<n.node_field.set_value value="[n.page_node.id/]"/>
<n.form. macro="reply">
  <span data-test="[n.page_node.id/]" data-test2="[n.node_field.value/]"></span>
</n.form.>

And the resulting output, viewed in Firebug, is:

<form accept-charset="UTF-8" action="/template/NamlServlet.jtp?reply" method="POST">
   <input type="hidden" value="reply" name="macro">
   <input type="hidden" value="3922655" name="node" id="node">

   <span data-test="3924753" data-test2="3924753"></span>
</form>

The SPAN reveals that the value of the form was changed -- yet somehow, the old value (the ID of our site's root node) persisted and was written to the relevant INPUT element. The wrong value gets written, preventing the website bug fix from working.

For a specific example of the problem, try using the Quick Reply form in threads Testing Perfection (link in signature). The code affected by this bug is in TP's "reply_enhancements" NAML file.