Bug Report - Thread "sunk" without any explanation as well as listing incorrect "last post" date

Hi, I posted a bug report on the D10 sheets a quite a while ago, and suddenly stopped getting replies in it. I decided to investigate, and found that I couldn't even find it on the boards anymore. Finally, I discovered that it was still in existence, but had apparently as good as disappeared. The forum post initially also listed the wrong "last post" date, being wrong by&nbsp; over a month. A user helped me find it - it had apparently dropped incredibly far down the list, and was now found among the posts that it shared it's wrong "last post" date with, but now the "last post" date has corrected itself, yet it still remains sunk. Another user informed me that the board has a "sink" function, which is functions like a reverse "sticky" function, but he seemed somewhat puzzled as to why the post was sunk. I acquired some insight into the matters by re-posting my bug and linking to the old post, and I'm not making this because the sink issue was taking focus away from my original bug-report. Below is a link to the actual post that was sunk. <a href="https://app.roll20.net/forum/post/3627954/bug-with" rel="nofollow">https://app.roll20.net/forum/post/3627954/bug-with</a>... Below is a link to the post in which we've so far discussed the matter, but I've requested that we stay on topic in that post, so please post further responses to this issue here instead - and please READ the below forum thread up until the post where I request we stay on hand, before you ask any questions. <a href="https://app.roll20.net/forum/post/3887762/data-dis" rel="nofollow">https://app.roll20.net/forum/post/3887762/data-dis</a>... here is a picture that shows the issue - unfortunately I was unable to get a picture from when the date was still wrong: My goal with the post is not to have explained how the forum works or any such - Rather I'm just interested in calling attention to the fact that my post was sunk for no apparent reason and that it seemed to negatively impact the process of getting the bug, that I was reporting, resolved. You are welcome to post your own theories as to why you think this happened, or go into lengthy technical monologues about how the forum works and what may have caused the bug - but I will neither be particularly interested in these explanations, nor do I think I will understand them at all. I mean no rudeness with this, but I'm not a forum dweller, and I hardly ever take any interest in forums excepting for bug reports, so forgive my apparent apathy.

Seems tzo have happened to me just now but I can't find the post again.

Grimtina said: Seems tzo have happened to me just now but I can't find the post again. Try searching for the post - then edit your own post if you get a link and post the link in the post you just made. Perhaps someone can look into whether it is a similar issue.

Hey, sorry the old message took so long to get a response. In your last message you said that you were going to have your players go through the steps I mentioned, so I was waiting for that extra information. When you finally came back with that extra info, it was right before the weekend so I wasn't around to see it until today. I'm sorry this issue has taken so long to fix. It's nearly impossible for me to find a bug when I don't know what is broken. Usually, if I am able to reproduce it myself, it's really easy to track down because I can dig into the error on my own end. But, in this case, I can't actually get it to break on my end. So, I'm having to try and do all of the digging through you and your players...which is always a very slow process because this isn't your job and you, presumably, don't want to spend your time "working" trying to fix this stuff. So please, bear with me and we will get this taken care of, it just might take a little while. Now, for the actual issue. I see, in the new posts, that you have some new debugging information for me. This will be helpful, any new error messages will help point me in the direction of this bug. I'm assuming this error popped up once your player had started seeing the issue in action, and this was what happened when he tried to select a new "dot". A javascript error would explain why the information isn't being saved properly on the server side, it's breaking before it actually gets saved. When I played over the weekend I had some issues when some of my players had their sheets popped-out with information not being properly synced between the external window and the rest of the game. Do you happen to know if your players were playing with their character window popped out when they were having the syncing issues? This could also explain it. (not that I know exactly why the popped out windows weren't working, but at least it's something I'm going to be looking into)

Hi, No sweat - sorry for jumping the gun and assuming my post had basically gotten abandoned, though it did seem to be the likely case, what with the strange post-sinking and all. Anyway, I think several of my players use the pop-out function due to using laptops (small low resolution monitors) yes. I will try telling them not to do that and see if the situation improves. I mean, obviously we will provide any information you need that is within out skill sets to provide - but honestly, you're very lucky that we have three guys in the group who study computer science in our group who can actually do the leg work on our end. The funny part is, we have a modified version of the D10 sheet that my friend made himself, because we wanted some changes, and that one works flawlessly, we just haven't uploaded it because we have no use for it in this particular game we're playing.

If they are using the popout, I think that might have something to do with it. But, just in case would you mind sharing a&nbsp; gist of the custom sheet you have that works. This way I can compare the 2 and see if something jumps out at me that might be the culprate.

I'll try to requisition the files.

Update: I've tested it - the problem persists even when NOT using the pop-out function.

Dang... You're really not making this easy on me. :P I'll hopefully have some time tomorrow, Friday, to do some digging. When you were able to reproduce it real quick (in your last post), do you have some steps that consistently make that happen? When you did that does the same bug your player had pop up?

heh, sorry - I just thought we'd found the reason too - a lot of my players DO use that method, so it almost fit, but no cigar! Still working on getting that sheet. Will post back if I have it. Tell you what Phil, I'll try to get every single one of my players to write a description, in their own words, of when the bug(s) occurs and post them here. Me personally? I think the annoying part about this bug is, that it isn't 100% reproducible, because sometimes it simply doesn't happen, and at other times, it only erases SOME of your data. Let's say I was filling out a sheet for a new NPC, and I decide to spend 22 skill points across the 3 skill trees listed (mental, physical and social), listed in vertical order on the first page. I fill them all in, then I progress to fill in 7 merit points in the merit list on the first page. I pick 2 merits. Then I close my sheet and decide to take a break, perhaps look up some more merits from the source book. I open the sheet back up, and lo and behold - my merits are gone, both of them, and perhaps most of my skill points too. I can't say that it's any particular action that I take that guarantees the fact that the sheet refuses to save my data - the only thing I can say, is that, it is SOMETIMES possible to make the sheet save text you have JUST written in, by clicking in a different box and possibly writing something in it. I can also say that many players report that clearing their cache seems to have helped, but not solved the issue, just lessened it's frequency.

New information: Daniel H. from my group got the idea that the problem might happen somewhere on the roll20 server rather than with the sheet code, because he looked at the code and says that the sheet looks completely fine according to his own knowledge - and seeing as for some reason, when ever we use a custom sheet that Daniel H. made, the problem didn't occur. So Daniel downloaded the sheet (WOD werewolf sheet), and then we uploaded it completely unaltered as a custom sheet. Now the problem appears to be gone... Though we've only done small tests, so I cannot truly confirm that it is solved. Because Daniel has been experiencing the problem much less than the rest of us, so Daniel has talked me into running a placebo test on my players, so I will refrain from telling them that I've uploaded a custom version of the old sheet (seeing as they are identical, the sheet appears to be already filled out) and then see if they still experience the issue.

Here are the statements I got from them, when I asked them to explain when they get the issues. I have to admit they didn't exactly stick to the script, but what can you do, it may still help: From Tristan P. Right, I can Replicate the issue on command. It appears that the Abilities and Specialties issue is entirely fixed so far as i can tell, but the Merits tab is still wonky. You cannot both add a merit and write its name, and fill out its dot rank at the same time, Only the name will take and then you must exit the sheet. You also cannot fill in the info for more than 1 merit at a time, as any information entered after the first ones name will be wiped clean when you exit the sheet. From Daniel H. This is not a sheet problem but something that exist in roll20 for a long time we have not noticed because I made more merits and did not allow the pointless creations of more merits by a javascript. From Jonas S. I have not tested it particularly. For me, it mostly seems to affect creation of new merits, etc. (when a new bunch of elements are added to the sheet), which it doesn't save. It does appear that they mostly seem to agree that the problem is centered on merits, and Daniel believes that it's mostly centered on the function that creates a new box to write in. That said, we've (as a group) experienced this problem across the board, so while merits may indeed be the major culprit, it's a difficult problem to pin down. I feel like we're probably experiencing more than one bug, but we (as players) just lack the ability to differentiate between them.

I think I may have found something. I can reliably replicate the errors by doing the following: 1) Add a repeating Merit or Gift using the +Add button. 2) Enter a name for the Merit or Gift. 3) Select the rank for the Merit or Gift. 4) Click back in the name field for this Merit or Gift. 4a) Edit the name.of the Merit or Gift at this point. 4b) Set a new dot rank. 5) Close and re-open the sheet. 6) The dot rank for the new Merit or Gift is not recorded. If you changed the name of the Merit or Gift in step 4a, only the original name is there. I was following good practice to click out of fields to shift the focus so values could be recorded, but it failed in this case. Pondering this I realized I was only clicking within the new repeating section . I followed the above steps making sure to click an entirely different field in Step 4. Using this technique, values for name and rank were reliably saved between sheet closings. This led me to examine the sheet's HTML code. Here is the repeating section for Gifts: &lt;fieldset&nbsp;class="repeating_Gifts"&gt; &lt;table style="width:100%"&gt; &lt;tr&gt; &lt;td&gt; &lt;input type="text" name="attr_repeating_Gift_name" style="width:120px" /&gt; &lt;/td&gt; &lt;td&gt;&nbsp;&lt;/td&gt; &lt;td&gt; &lt;input type="radio" class="sheet-normal sheet-zero" name="attr_repeating_Gift" value="0" checked="checked" /&gt;&lt;span&gt;&lt;/span&gt; &lt;input type="radio" class="sheet-normal" name="attr_repeating_Gift" value="1" /&gt;&lt;span&gt;&lt;/span&gt; &lt;input type="radio" class="sheet-normal" name="attr_repeating_Gift" value="2" /&gt;&lt;span&gt;&lt;/span&gt; &lt;input type="radio" class="sheet-normal" name="attr_repeating_Gift" value="3" /&gt;&lt;span&gt;&lt;/span&gt; &lt;input type="radio" class="sheet-normal" name="attr_repeating_Gift" value="4" /&gt;&lt;span&gt;&lt;/span&gt; &lt;input type="radio" class="sheet-normal" name="attr_repeating_Gift" value="5" /&gt;&lt;span&gt;&lt;/span&gt; &lt;/td&gt; &lt;/tr&gt; &lt;/table&gt; &lt;/fieldset&gt; Note that the attributes inside the repeating section are named with attr_repeating , which should only designate a repeating section, not one of its attributes. The repeating section for Merits does the same. I think Roll20 gets confused by this. I edited the code, removing the "repeating" from the attribute names, reloaded my game, and repeated my steps above and the problem seems to be gone. Hope this helps.

Rabulias said: I think I may have found something. I can reliably replicate the errors by doing the following: 1) Add a repeating Merit or Gift using the +Add button. 2) Enter a name for the Merit or Gift. 3) Select the rank for the Merit or Gift. 4) Click back in the name field for this Merit or Gift. 4a) Edit the name.of the Merit or Gift at this point. 4b) Set a new dot rank. 5) Close and re-open the sheet. 6) The dot rank for the new Merit or Gift is not recorded. If you changed the name of the Merit or Gift in step 4a, only the original name is there. I was following good practice to click out of fields to shift the focus so values could be recorded, but it failed in this case. Pondering this I realized I was only clicking within the new repeating section . I followed the above steps making sure to click an entirely different field in Step 4. Using this technique, values for name and rank were reliably saved between sheet closings. This led me to examine the sheet's HTML code. Here is the repeating section for Gifts: &lt;fieldset&nbsp;class="repeating_Gifts"&gt; &lt;table style="width:100%"&gt; &lt;tr&gt; &lt;td&gt; &lt;input type="text" name="attr_repeating_Gift_name" style="width:120px" /&gt; &lt;/td&gt; &lt;td&gt;&nbsp;&lt;/td&gt; &lt;td&gt; &lt;input type="radio" class="sheet-normal sheet-zero" name="attr_repeating_Gift" value="0" checked="checked" /&gt;&lt;span&gt;&lt;/span&gt; &lt;input type="radio" class="sheet-normal" name="attr_repeating_Gift" value="1" /&gt;&lt;span&gt;&lt;/span&gt; &lt;input type="radio" class="sheet-normal" name="attr_repeating_Gift" value="2" /&gt;&lt;span&gt;&lt;/span&gt; &lt;input type="radio" class="sheet-normal" name="attr_repeating_Gift" value="3" /&gt;&lt;span&gt;&lt;/span&gt; &lt;input type="radio" class="sheet-normal" name="attr_repeating_Gift" value="4" /&gt;&lt;span&gt;&lt;/span&gt; &lt;input type="radio" class="sheet-normal" name="attr_repeating_Gift" value="5" /&gt;&lt;span&gt;&lt;/span&gt; &lt;/td&gt; &lt;/tr&gt; &lt;/table&gt; &lt;/fieldset&gt; Note that the attributes inside the repeating section are named with attr_repeating , which should only designate a repeating section, not one of its attributes. The repeating section for Merits does the same. I think Roll20 gets confused by this. I edited the code, removing the "repeating" from the attribute names, reloaded my game, and repeated my steps above and the problem seems to be gone. Hope this helps. Right - the initial explanation is pretty much what I tried to explain was going on. I can confirm that this is more or less the problem we're experiencing. The thing is, we (periodically) experience the problem, even WITHOUT the involvement of the "repeating" functions, but it is definitely MORE problematic with repeating functions. Attributes would be the only thing I have DEFINITELY never seen the problem occur with - skills, specialties, merits and gifts have all suffered from this. Edit: Also, holy cow bells, someone from outside our group has replicated the problem. This is a great step for mankind. I was seriously starting to feel like an online hypochondriac.&nbsp;

You guys are amazing, thank you for all the help in tracking this down. I'm going to take all of this new info and look into it today! &nbsp;Okay, I lied, by the time I finished the rest of stuff I had to do I was feeling crapy, and have been out of work with a fever since then. I should actually have time today to look at it. (if my fever doesn't come back again)

I have some awesome news! I have figured out what the issue is, totally thanks to Rabulias for figuring out that it is triggered by modifying a "repeating section" row. Which explains why it felt like it happened "randomly". Once it was triggered, the worker for that character errors out and stops working until you open the sheet again. This explains why other sections would have issues as well, the borked worker stops saving everything until the sheet is re-opened. Now, as for why this was only happening with this particular sheet, it's happening because of the naming convention used for the individual pieces of each row, again just like Rabulias guessed. This is definitely something that shouldn't happen, people shouldn't be able to break the code on our end. No matter how they name stuff. Rather than "fix" the sheet to match some arbitrary rules, I'm going to fix our back-end to be more careful on how it handles these situations. Hopefully I'll be able to fix and push out the fix before the weekend. If I'm not able to you can use a "custom" sheet and just remove the "_repeating" parts inside of the repeating rows. (the elements that are named "attr_repeating_something", not the ones that start with "repeating_") Definitely thank Rabulias for figuring out that it was specifically tied to the repeating sections, once I looked there it was super easy to figure out.

Happy to help! :-)

The fix is live now. The javascript shouldn't break because of the weird naming convention in the sheet. I ran through several tests to make sure that the repeating sections were saving correctly and everything seemed to work as intended. Thank you again for taking the time to work with me and get this crazy bug figured out!

We will test it soon and of course let you know if we have any problems again - but we're very happy to hear that it was fixed. Thanks for your help!