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

[DavidJCobb]

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.

[Pedro]

Ok. I'll try to fix it.

[Pedro]

Please, look your reply_enhancements_js it seems that your script is searching for the input named "node" and setting its value after the naml create the page. Make sense?

[DavidJCobb]

Pedro <Nabble> wrote

Please, look your reply_enhancements_js it seems that your script is searching for the input named "node" and setting its value after the naml create the page. Make sense?

Did you look at the NAML for Reaching Perfection, or the NAML for Testing Perfection?

Reaching Perfection has a band-aid fix that uses JavaScript, so that our members don't have to tolerate the bug while a real fix is worked on.

Testing Perfection still has the problem -- the field's value is changed before a macro is called, yet that macro's output writes the old value.

[Pedro]

DavidJCobb wrote

Did you look at the NAML for Reaching Perfection, or the NAML for Testing Perfection?

Testing Perfection still has the problem -- the field's value is changed before a macro is called, yet that macro's output writes the old value.

I've looked Testing Perfection. In this forum, Testing Perfection, that I'm asking you if there is some script that are changing the node input.

[DavidJCobb]

Pedro <Nabble> wrote

DavidJCobb wrote

Did you look at the NAML for Reaching Perfection, or the NAML for Testing Perfection?

Testing Perfection still has the problem -- the field's value is changed before a macro is called, yet that macro's output writes the old value.

I've looked Testing Perfection. In this forum, Testing Perfection, that I'm asking you if there is some script that are changing the node input.

OH, I think I know what you mean.

If you click "Reply" on a post, then the Quick Reply form attaches to that post, and the node field is changed by a script.

If you just use the Quick Reply form without clicking "Reply" on anything, however, the node field retains the value that the NAML code writes out. That value should be the ID of the page_node (first post in the thread), but instead, it is the ID of Testing Perfection's root node. The NAML bug I'm reporting makes it impossible for me to fix the value using just NAML.

So what ends up happening is that some users use the form without picking a specific post to reply to. This should result in them sending a reply to the first post in the topic, but instead, their reply becomes a direct child of the site's root node.

[Hugo <Nabble>]

We just found an issue in the code and released a fix that should solve your problem. Please try again now and let us know if it is working properly.

[DavidJCobb]

Just checked; the correct value is now being written to the page. Thanks :)

[Hugo <Nabble>]

That's great. It was a small javascript bug in a recent change to the search box. Thanks for reporting this issue.