this post was submitted on 14 Jan 2024
4 points (100.0% liked)
/kbin meta
5 readers
2 users here now
Magazine dedicated to discussions about the kbin itself. Provide feedback, ask questions, suggest improvements, and engage in conversations related to the platform organization, policies, features, and community dynamics. ---- * Roadmap 2023 * m/kbinDevlog * m/kbinDesign
founded 1 year ago
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
@shazbot @speck
For me, the culprit is the collapsible comments mod (or the standalone script if you're using that one).
edit: The root cause seems to be lines 182 to 190. But the actual troublemaker appears to be on kbin's side, not KES. When the mod's main function finishes, the comment still only has only one .more element like when it began.
I've disabled all other mods and userscripts, so it's not one of those. Also just tried to disable KES (and even the monkey) entirely, running the script from the console instead. No change either, it's still happening.
The code fragment in question copies the comment into a new children container. I'm thinking this probably makes some part of kbin confused, leading to the issues we're seeing.
It might be best to just include the userstyle I'm using in the CSS added by the mod.
This is the code between lines 182 and 190, removing which prevents the issue:
@Pamasich @speck
I have completed an audit of the mod and observed the following issues:
Does not properly unset classes and restore the page to an intact state when turned off: this was having the side effect of making the threaded lines look incorrect when toggling on/off in place. The mod should not leave dangling containers around after it is toggled off. The mod creates an outer container so that the "expando" lines flow all the way down through the child elements, but when turned off, these child elements need to be moved back out of the container to be adjacent to each other and the container removed. => Fixed locally.
Does not properly unset event listeners attached to nested comments. Same as above, tends to leave dangling listeners and does not unset itself cleanly. => In progress.
Because it physically manipulates the DOM and moves sub-comments into their own container down the tree, triggers an event (likely a bug) on Kbin's side whereby any time the DOM is updated for that element, Kbin appends a
more
element (text expansion button) if the text overflows a certain length, even if amore
element is already present. You can test this by creating a dummy div above or below a long comment and then moving the long comment before or after that div. Simply moving its position in the DOM will trigger the creation of anothermore
element inside. And because the mod puts each comment into its own container for the purposes of threading nested chains of comments, this will trigger the creation of as manymore
s as there are indendation levels. So for a comment chain 5 replies deep, there will be 5more
s. This is further exacerbated when toggling the mod on and off, since thesemore
s are not getting wiped and will just keep getting stacked up. Since this is also an upstream issue, our only alternative here is to walk through the tree and remove the extraneousmore
elements after nesting occurs. This is similar to your CSS solution, but instead of masking them, physically deletes them, otherwise we will have a constantly growing tree ofmore
s every time nesting happens. I guess this should also be reported upstream as well. Kbin seems to expect no DOM manipulation to occur, which is reasonable, I suppose, but might be better if the callback doesn't insert themore
element at all if it's already present. => Easy fix on the Kbin side, in progress.Thanks for looking into this. I've been meaning to audit this mod, but was a bit busy this week. In light of this report, this seems like as good a time as any.
Unfortunately, the mod is no longer maintained by the original author, so I'll have to inherit it and refactor it. I feel it is overengineered for what it attempts to do, so it should be streamlined and the aforementioned issues fixed. I am also aware of the issue that the mod fails to unset itself properly when turned off. I am really not satisfied with its current functionality.
Root cause analysis and solutions are described in a subsequent comment
@Pamasich
I have resolved the aforementioned issues with a hotfix on the testing branch; please test when time permits. Executive summary:
more
s are being removed now for comments with overflow text. What I thought would be a quick fix turned into hours, and I thought I was losing my marbles over this one for a long time, since the tree clearly showed numerous duplicatemore
s, but only one per comment was being shown at runtime of the script. At first, I did not seriously think that the mod was completing its runtime cycle prior to the duplicate mores being spawned, but indeed this is what was happening. For now, I have added a 20ms sleep before clearing the extramore
s, and this seems to suffice to let them propagate before the mod can continue with the cleanup phase. This seems satisfactory for now, short of attaching observers to wait for the duplicatemore
s to appear.I believe that covers everything. It should be possible to switch the mod on and off at will now and see no adverse effect.
Teardown isn't working for me, tried multiple devices and turned my custom styling off.
After teardown this is how the site looks like to me. Also, it seems you need to remove the mores on teardown too. The more issue is now fixed when the mod is active, but appears again after teardown.
I had just forgotten something simple (unload the threaded comments CSS):
Before:
After:
This is live on testing, but might take a sec to propagate due to GitHub's caching feature.
This works for me now.
You're right, looks like I missed something that was obscured by custom styling.
And good catch on the mores appearing on teardown. This mod is turning out to be quite a beast. Thanks for testing.