Tried to reproduce this with a coordinator and non-coordinator user but it appears to be working as intended for me.

@Xover - could you let me know which browser (and version) you're using?

See also T190431 where another user reported not being able to see comments properly, on iOS. We never heard back about whether the problem was solved but again we couldn't reproduce the issue.

Observed on the last couple of release versions of Safari on macOS 10.13.4 and .5, and mobile Safari (iOS) on the last major release (11.3.1). Using the 1Blocker content blocker, but with *.wikipedia.org, *.wikimedia.org, and *.wikisource.org whitelisted (just to be sure: nothing on WMF sites should really be blocked to begin with).

I haven't tried testing without the content blocker or in a different web browser, mainly because on at least one previous occasion I've commented that I couldn't see the comments without a response from the coordinator, which I took to mean they couldn't see my comment either. The alternate explanation is, of course, that they were just too busy and it's just an issue with my setup. I'll try to find time to do some testing with these variables later today.

Sigh. Yes, it was the content blocker. :facepalm: I should have double checked that first of all.

The comments on the Library Card Platform are triggering the rules that block comment sections on websites in 1Blocker because they're wrapped in a div#comments. And my whitelist didn't work because it's at *.wmflabs.org, which I hadn't whitelisted; and which, of course, was obvious once I actually started looking at it. 😊

While I go wipe the egg off my face, I'll suggest you tweak that id attribute to be "#lcp-comments" or some such that stands a better chance of not hitting content blocker rules for the benefit of others.

Had a look into this today. It's actually going to be a less straightforward fix than just renaming a div.

We use django-contrib-comments for application commenting, simply generating the list of comments with render_comment_list, which automatically fills out the comments/list.html template, containing the offending "comments" id. You can render the comment list out manually, but the comment model isn't very useful because it doesn't contain the editor's wp_username, just their platform username, which is an ID. It's not clear to me how the default render behaviour finds a user's wp_username to display in the template.

A few thoughts:
I'm not even sure if we should fix this, since blocking comments is one of the design goals of this addon. @Xover might be interested to know that the makers of 1blocker have also released 1blocker x, which appears to be designed to address this concern for their users.