Javascript error on cancel of the block user modal.
Closed this issue · 7 comments
Environment
- python version 3.6
- django Version 3.2
- django-comments-dab 2.7.0
Describe the bug
Closing the "block user" modal raises a javascript error and the modal fails to close.
15:05:52.214 comment.js:41 Uncaught TypeError: Cannot read property 'classList' of null
at hideModal (comment.js:41)
at HTMLDocument.<anonymous> (comment.js:790)
Steps To Reproduce
- post a comment
- login as admin
- click the lock icon to block a user, and cancel the block modal
Expected behavior
Cancel the action and close the modal.
Screenshots
If applicable, add screenshots to help explain your problem.
At a guess after glancing around the js file, it seems this might be related to selection functions for disabled feature modals. It seems to find "nearest" as followModal or CreateAnonymousCommentModal, both of which I disabled in settings.
If I remove the hide functions for those (follow and CreateAnonymous) modals (around lines 40-50), as well as the references to those functions in the click listener (around lines 790-800) the problems go away.
Thanks for taking the time to report the issue, and on its initial investigation, i also get an error after closing the modal for blocking the user. although the modal closes successfully for me, i get an error:
Uncaught TypeError: createAnonymousCommentModal is null
hideCreateAnonymousCommentModal http://localhost:8000/static/js/comment.js:46
<anonymous> http://localhost:8000/static/js/comment.js:792
i will try to investigate more on this. if you could give me additional information about the custom settings that you're using for django-comments-dab
, it would be great.
@awhileback can you verify whether the linked pull request fixes your issue?
PROFILE_APP_NAME = 'users'
PROFILE_MODEL_NAME = 'CustomUser'
COMMENT_PROFILE_API_FIELDS = ('user_name')
COMMENT_USER_API_FIELDS = ['id', 'user_name']
COMMENT_PER_PAGE = 50
COMMENT_FLAGS_ALLOWED = 10
COMMENT_FROM_EMAIL = os.environ.get('DO_EMAIL_ADDR')
COMMENT_ALLOW_BLOCKING_USERS = True
COMMENT_ALLOW_MODERATOR_TO_BLOCK = True
COMMENT_FLAG_REASONS = [
(1, ('Spam')),
(2, ('Abusive')),
]
COMMENT_ALLOW_SUBSCRIPTION and COMMENT_ALLOW_ANONYMOUS are both disabled by default per the docs (and can confirm, I don't see icons for them on the page) so I didn't bother explicitly disabling them in settings.
The linked PR still fails in a similar manner, it mentions the followModal on line 792...
Uncaught TypeError: Cannot read property 'classList' of null
at hideModal (comment.js:41)
at HTMLDocument.<anonymous> (comment.js:792)
Something that may be related, which I had to deal with while customizing the templates a bit...
I noticed when adding an icon for "reply" that the JS was looking for an Nth parent (by number) element to find the root of the current comment tree, and then selecting the reply div under that root element. That's all fine and good, but what I ran into is the <path>
element inside of an SVG counts in the Nth element count as far as javascript is concerned. I solved it by explicitly disabling click handlers from interacting with any <path>
elements in question.
The following seems to be a more reliable selector, for example, on lines 43-46...
// show and hide child comments
let replyLink = replyLinkElement => {
//getNthParent(replyLinkElement, 6).nextElementSibling.classList.toggle('d-none');
getNthParent(replyLinkElement, 6).querySelector(':scope > .js-replies').classList.toggle('d-none');
};
And adding pointer-events="none"
to the <path>
element on my reply icon fixed the selector missing if the mouse happened to hit a line defined in the <path>
in the SVG.
I probably need to check browser compatibility on those but they seem to work okay in Chrome, Safari, and Firefox on my laptop.
@awhileback Thank you so much for the information. I think the main cause of the issue is that there is being an attempt to close/hide a modal element that doesn't exist inside the DOM(document object model)
i have added the checks inside the hideModal
and showModal
functions to verify and process only if the element exists in the linked pull request. Would it be possible for you to verify this and confirm if this works on your end now?
Thanks, all working fine!
thanks, for checking and the relay of information back and forth.