Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

AO3-6392 Comment actions when replying in full page #4381

Merged
merged 25 commits into from
Sep 8, 2024

Conversation

ceithir
Copy link
Contributor

@ceithir ceithir commented Nov 10, 2022

Pull Request Checklist

Issue

https://otwarchive.atlassian.net/browse/AO3-6392

Purpose

As per the JIRA, fix extra actions showing up and the Cancel button being "stuck" when answering a comment in full page.

Testing Instructions

Follow the JIRA instructions.

At the end, also try to "Cancel" the reply in the new page. The page should reload instead of the wrong buttons sticking around. The comment box should now collapse properly, the button "Reply" shows up, and hitting it open the box once again.

Credit

Ceithir (he/him)

@ceithir
Copy link
Contributor Author

ceithir commented Jul 16, 2023

No, I didn't forget to add tests to this PR for over six months, it's just a trick of the light.

@@ -657,7 +657,8 @@ def redirect_to_all_comments(commentable, options = {})
delete_comment_id: options[:delete_comment_id],
view_full_work: options[:view_full_work],
anchor: options[:anchor],
page: options[:page]
page: options[:page],
only_path: true
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Conflicted about this.

On one hand, it does fix every issue I had in tests about being redirect to the wrong domain (example.com).

On the other, changing such a critical piece of code just so tests pass trigger every warning in my brain.

Copy link
Collaborator

Choose a reason for hiding this comment

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

Yeah, I'm normally not a fan of that either, and the alarm bells are screaming. But ignoring my knee-jerk "let's not do this," I can't think of a reason it shouldn't be only_path: true. We definitely prefer paths to URLs. I think the only reason we hadn't already changed it is we do something in nginx that means this wasn't actively causing issues when we were supporting both HTTP and HTTPS. So this is probably fine.

Totally not a trick to trigger a new build
@brianjaustin brianjaustin self-requested a review September 18, 2023 16:38
app/helpers/comments_helper.rb Outdated Show resolved Hide resolved
@@ -107,7 +107,7 @@
<% elsif comment.persisted? %>
<%= cancel_edit_comment_link(comment) %>
<% elsif commentable.is_a?(Comment) || commentable.is_a?(CommentDecorator) %>
<%= cancel_comment_reply_link(commentable) %>
<%= cancel_comment_reply_link(commentable, remote: !on_js_less_comment_form(commentable)) %>
Copy link
Member

Choose a reason for hiding this comment

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

It looks like this results in redirecting to the work page (assuming the parent comment is on a work) with the comments section collapsed. That does the job, but I'm not sure if it's the intended behaviour. Thoughts @sarken ?

Copy link
Collaborator

Choose a reason for hiding this comment

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

Do you mean when replying from the comment section or somewhere else?

I'm looking at the current behavior of the Cancel button on the reply form and what I see is:

  • if you're replying to a comment from an email link, e.g., http://test.archiveofourown.org/comments/5209801?add_comment_reply_id=5209801, it
    • redirects to the comment you're replying to without the reply form open if JavaScript is disabled
    • closes the reply form without reloading if JavaScript is enabled
  • if you're replying to a comment from the comment section on the work, it
    • redirects to the work with the comment section closed if JavaScript is disabled
    • closes the reply form without reloading if JavaScript is enabled

So if we're talking about from the comment section on the bottom of a work and not a page like the URL I provided, it's not ideal, but it does seem consistent. I guess in an ideal world it would leave the comment section expanded when it redirected to the work, but I'd probably call that out of scope.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Well...

While attempting to clean up a seemingly unused method, I accidentally found the source of the bug that I had tried to circumvent by forcing a redirection there. So it's not needed anymore as the form now collapses down properly even if the page started in "focused" mode, and everything is smooth in the best of worlds.

Hooray for serendipity?

Copy link
Member

Choose a reason for hiding this comment

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

Hah, I love when deleting code fixes bugs 😆

I guess it's less relevant now, but the case I was talking about was a special case of 2b: opening the reply link in a new tab (so ending up on a page like http://localhost:3000/chapters/170?add_comment_reply_id=42&show_comments=true#comment_42) and then clicking "Cancel"

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The first case of the if wasn't accessible anymore
As the form was hidden if the condition was true
features/comments_and_kudos/add_comment.feature Outdated Show resolved Hide resolved
features/comments_and_kudos/add_comment.feature Outdated Show resolved Hide resolved
features/comments_and_kudos/add_comment.feature Outdated Show resolved Hide resolved
@brianjaustin brianjaustin merged commit dade1c1 into otwcode:master Sep 8, 2024
29 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants