Comment module uses a global session variable to store referer, which can screw up redirect after posting.

Ah, this was that strange behaviour I have seen (and thought that some referer sessioned variable causes it). The problem with hidden fields is that with caching there will be problems... The problem with session variables is that multiple windows screw up. Maybe a different solution could be found? I have no idea yet...

the attached patch shows the correct node view with status message after a comment is successfully posted.

fix a typo

I've tested the patch and it works just fine for me. +1 from me for fixing this extremely annoying bug in the core.

I think we have to look for a more generic system that can be used for any form, and not limit ourselves to the comment forms. For example, when you are on the node overview page (admin/node), you click 'edit node', and click 'Submit', you end up looking at the node (node/view/xxx), and you might have to travel all the way back to the node overview page.

I've shared a quick patch a few weeks ago to attempt this, but it was not 100% either. Maybe we should look into that once more.

returning to 'active' status. the ideal patch has not arrived yet. until then, we suffer.

I'm in a better mood today, and posting a better patch. This patch assures that the page which is shown after add/edit/delete of a comment is correct. You are now shown the node upon which you commented, except in the Admin case when you are brought back to the admin/comment page. This was a bit screwy before, as an admin editing a comment from the usual interface used to get thrown into the admin section after editing.

Another benefit of this patch is that it removes a couple redirects [i.e. drupal_goto()], which cause unnecessary delay for the user, and a bit mre server load.

The technique used to achieve this is a querystring param called 'destination' is introduced as needed. When present, this param holds the _GET['q'] which should be shown after the post is accepted.

This same technique works for other forms like node and user. In fact, we already use this technique in the login form.

I will soon followup with a separate patch which addresses the admin/node case that Dries describes.

I'm not sure it is an issue here but pages with hidden destination fields can get cached (which is why I want to get rid of it for the login block). I'll test it out a bit.

the caching issue which dries mentions is not an issue. just try the patch and you'll see.

I committed an alternative solution to HEAD. We no longer show an incorrect page after posting a comment. My solution does not have an 'admin case' like Moshe's though. We need to find a generic solution for that as this affects more than just the comment administration pages. Marking this fixed for now.

Since this is a problem in 4.4.x too, why not commit a fix in there too?

A question on this one, guys.

I'm now running the HEAD version (after thinking I was upgrading to 4.4.1 - d'oh!!!) and have noticed something odd with posting comments.

After I post a comment, I am redirected to "comment/reply/###" (where ### is the node number), rather than "node/view/###". The page I'm redirected to doesn't show the comment I just posted, or any other comments. It just shows the node.

This doesn't seem right to me. Shouldn't I at least see the comment I just posted?

Just realised that this will probably get more attention if I switch it back to 'bug report'.

The current behaviour (redirecting you back to a page that doesn't show the comment you just posted) doesn't seem right at all.

Dries: My solution does not have an 'admin case' like Moshe's though. We need to find a generic solution for that as this affects more than just the comment administration pages. Marking this fixed for now.

My patch *did* have a generic solution. The source link may specify a destination path. That path will be shown after the form has completed its processing. I can't think of of a more "generic solution" than that.