Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Improve unfinished-comments detection logic - #3707

Merged
fregante merged 16 commits into
refined-github:masterfrom
cheap-glitch:fix-unifinished-comments
Nov 23, 2020
Merged

Improve unfinished-comments detection logic#3707
fregante merged 16 commits into
refined-github:masterfrom
cheap-glitch:fix-unifinished-comments

Conversation

@cheap-glitch

@cheap-glitch cheap-glitch commented Nov 7, 2020

Copy link
Copy Markdown
Contributor

Thanks for contributing! 🍄

  1. LINKED ISSUES: Add unfinished-comments feature #3694 (cf. this comment)

  2. TEST URLS: Improve unfinished-comments detection logic #3707

  3. SCREENSHOT: n/a

@cheap-glitch

Copy link
Copy Markdown
Contributor Author

The feature should now work correctly in both of these cases:

  • when a comment is submitted from a hidden tab
  • when a comment is submitted from a hidden tab but there are still some drafts in the page

Comment thread source/features/unfinished-comments.tsx Outdated
documentTitle = undefined;
} else if (document.visibilityState === 'hidden' && hasDraftComments()) {
function updateDocumentTitle(): void {
if (document.visibilityState === 'hidden' && hasDraftComments() && !documentTitle) {

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I know it's ugly, but the nested if was here to account for the case where a comment is sent from a hidden tab but there are still drafts somewhere on the page (and thus the title shouldn't be reset).
But maybe this possibility doesn't exist in the first place?

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You're right, the 2 conditions aren't equivalent when "is hidden, has draft and has a documentTitle". I don't know if it matters at the moment because the change doesn't fix the issue, as mentioned in the other comment.

@fregante

fregante commented Nov 7, 2020

Copy link
Copy Markdown
Member

I tested both your last commit and my commit, and neither one actually catch the situation described by #3694 (comment)

submit might happen when the user is still on the page, but the page can be updated when it's hidden.

If possible, perhaps, the easier way is to exclude "sending" textareas in hasDraftComments, example:

	return select.all('textarea').some(textarea => textarea.value.length > 0 && textarea.offsetWidth > 0 && !textarea.closest('.is-sending')); // made-up class

@cheap-glitch

Copy link
Copy Markdown
Contributor Author

If possible, perhaps, the easier way is to exclude "sending" textareas in hasDraftComments

So the solution would be to mark the submitted forms with a class/attribute in the submit listener?

@fregante

fregante commented Nov 8, 2020

Copy link
Copy Markdown
Member

I expect GitHub to already be doing that, so look for such a class in the dom first.

@cheap-glitch

cheap-glitch commented Nov 8, 2020

Copy link
Copy Markdown
Contributor Author

I expect GitHub to already be doing that, so look for such a class in the dom first.

Maybe I didn't look in the right place, but I found no such class.

EDIT: I went ahead and implemented a proper fix using a custom class to tag the sending forms. Tested in both Firefox and Chromium and it works as expected.

@fregante

fregante commented Nov 9, 2020

Copy link
Copy Markdown
Member

Maybe I didn't look in the right place, but I found no such class.

The fields and forms don't appear to have the class, but what do you think about looking for non-disabled Comment buttons instead? This slightly complicates the selector to cover the various types of comments and merge commits descriptions, but we wouldn't have to check the content nor the visibility.

Example:

a212

@cheap-glitch

Copy link
Copy Markdown
Contributor Author

The fields and forms don't appear to have the class, but what do you think about looking for non-disabled Comment buttons instead?

After a few quick tests, I see two problems with this approach:

  1. There are a lot of buttons with the same (or very similar) attributes as the Comment buttons, and those are not disabled but simply hidden. I'm afraid we would still have to rely on checking visibility, parent elements or text content and that would complicate things quickly.

  2. The Comment buttons associated with replies to code comments never get disabled (at least on Firefox) even when the corresponding textareas are hidden, blurred and/or empty — except for a very brief moment when the comment is posted.

@yakov116 yakov116 added the bug label Nov 10, 2020
Comment thread source/features/unfinished-comments.tsx Outdated
Comment thread source/features/unfinished-comments.tsx Outdated

@fregante fregante left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok I found a solution for the class removal.

Comment thread source/features/unfinished-comments.tsx Outdated
Comment thread source/features/unfinished-comments.tsx Outdated
Comment thread source/features/unfinished-comments.tsx Outdated
Comment thread source/features/unfinished-comments.tsx Outdated
return select.all<HTMLTextAreaElement>('textarea:not([disabled])').some(textarea =>
textarea.value !== textarea.textContent && // Exclude comments being edited but not yet changed (and empty comment fields)
textarea.offsetWidth > 0 && // Exclude invisible fields
!textarea.closest('.rgh-is-sending-comment') // Exclude forms being submitted

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this would cover:

  • regular comments
  • review comments
  • PR merges
Suggested change
!textarea.closest('.rgh-is-sending-comment') // Exclude forms being submitted
select.exists('.btn-primary[disabled]', textarea.form!);

This reads as: if the form of the current textarea (which is filled, changed, and visible) contains a disabled "submit" button, then the textarea is being sent.

I'm not sure if the selector needs to be tweaked.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tested all three cases and they work great! Although the feature doesn't work when creating a new issue/PR — but I don't think it was the goal in the first place?

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that's just due to pageDetect.hasComments. Perhaps the correct one is hasRichTextEditor

@fregante fregante changed the title Reset document title when draft comment is submitted Improve unfinished-comments detection logic Nov 23, 2020
@fregante

Copy link
Copy Markdown
Member

Thanks @cheap-glitch!

@fregante
fregante merged commit 0ad621e into refined-github:master Nov 23, 2020
@cheap-glitch
cheap-glitch deleted the fix-unifinished-comments branch November 24, 2020 08:31
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Development

Successfully merging this pull request may close these issues.

3 participants