If I go to bugs.python.org, get default page with recent activity, fill in name,pass, hit [login], I get, with red background
"broken form: multiple @action values submitted"

If I go to search page and do same, I do get logged in.
If I do a search and do same from results page, get same error.
This is new behavior.

Win7, 64 bit, FireFox 11

If you e.g. click on the logout link, you get redirected to http://bugs.python.org/?@action=logout.  IIUC you get an error because if e.g. you try to login again, the same url is used as target by the login form (<form method="post" action="#">) so the server receives an action via POST (<input type="hidden" name="@action" value="Login" />) plus the old one via GET (@action=logout in the URL).  I had this problem while switching between users, and the workaround was to go to homepage (e.g. bugs.python.org) after the logout in order to avoid having extra "action" in the URL when I was logging in again.
If we change the target to use only the name of the page, we should be able to solve the problem, but we will lose the ability to get back to the exact page we were visiting after a login (that shouldn't be a big problem though).
Note that the problem also affects the "show issue" form and possibly other forms.

Oh, I hate web sites that don't take me back to exactly the page I was on after I log in.  -1 on that proposal.  We could strip @action's from the URL, though, that would make sense.

Ezio: but you would have a green bar "You are logged out - clear this message", right? And if you follow the "clear this message" link, you get to a URL with no action, right? So I doubt this is what Terry did.

Terry: can you reproduce this (I can't)? If so, please give exact reproduction steps. How exactly did you go to bugs.python.org?

I can reproduce it for the search case. In that case, stripping the action is not a good idea.

I think the __came_from field should include query parameters.

> Oh, I hate web sites that don't take me back to exactly the page I was on after I log in.

I said it wouldn't be a big problem because if I'm not logged in already, I usually do it to reply to a message, and in that case you would be sent back to the right issue page (issueXXXXX).  It wouldn't work for searches or one of the "summary" query though, because it would redirect to the "issue" page.

> Ezio: but you would have a green bar "You are logged out - clear this message", right?

Yes

> And if you follow the "clear this message" link, you get to a URL with no action, right?

Yes, but I usually just click on the logo on the top-left (note that logging out already redirects to the list of issues).

> So I doubt this is what Terry did.

I only encountered this problem while switching accounts on my test tracker (so logout+login), it never happened to me on the regular tracker (probably because I never had to combine login/logout/search there).

Ezio is correct that the problem is having an 'action=xxx' in the url while doing a login. Logout -- back to main page but with url such as
http://bugs.python.org/issue?@action=logout&@pagesize=50&@startwith=0
instead of simple
bugs.python.org
(how I usually start from history) is the obvious way to trigger it.
I am not sure how I triggered this. Perhaps I hit 'logout' instead of 'your details'.

Why is 'action=logout' in the url? It has already happened and is not to be repeated. The remainder is not needed as it is the default. In this case, http:bugs.python.org would be enough, except maybe for a page to return to. Or the action should be, if anything 'login', not logout.

The other way to trigger the problem is to go to site, do a search, and get to a url is something like the following, with most invisible
http://bugs.python.org/issue?%40search_text=module&ignore=file%3Acontent&title=&%40columns=title&id=&%40columns=id&stage=&creation=&creator=&activity=&%40columns=activity&%40sort=activity&actor=&nosy=&type=&components=&versions=&dependencies=&assignee=&keywords=&priority=&%40group=priority&status=1&%40columns=status&resolution=&nosy_count=&message_count=&%40pagesize=50&%40startwith=0&%40action=search
including the 'action=search' at the end. Now remember "Oh, I forgot to login" and hit login. Red message. This is a bug in my opinion.

Here, perhaps the url is needed to return to the page, but does the search need to be repeated? Even if so, why are multiple actions prohibited?

I usually don't bother or remember to login until I am on an issue page, whose url has no action, and decide I want to comment or change headers. Or I go directly to an issue page from the Friday report. So I am probably wrong about problem being new, except to me.

> Why is 'action=logout' in the url? It has already happened and is not to be repeated.

IIUC this happens because Roundup uses GET for the logout, so in order to logout you have to go to a page that contains action=logout in the URL -- e.g. the page you go to by clicking the "Logout" link.

> Here, perhaps the url is needed to return to the page, but
> does the search need to be repeated?

Most likely, unless the login/logout is implemented via AJAX (but that's impractical since the content of the page usually changes when you log in/out).

> Even if so, why are multiple actions prohibited?

The problem here is that Roundup is mixing GET and POST, normally you would have only one action, and having more actions might result in a conflict (e.g. login+logout).  Instead of giving an error Roundup could ignore the GET action if there's already a POST one, or use POST for the logout too.

> I usually don't bother or remember to login until I am on an issue page,
> whose url has no action, and decide I want to comment or change headers.

This is what I usually do, that's why I said that usually it wouldn't be a problem removing all the GET args from the URL.

> Why is 'action=logout' in the url? It has already happened

Wrong. The URL you are seeing is the very one that did the
logout. This is how web browsers work: they show you the URL
that corresponds to the page you are seeing. Likewise for
your other suggestions and questions.

This also occurred for me having done a search, then login to add a bug. Considering this is a standard workflow when seeing a bug to report (search first, so as not to add a duplicate), then the login action at least should support this some way - perhaps the url should be "action=login&original_action="urlescaped end of original" such that a successful login can redirect to the logged in version of the previous action.

I am bumping this to urgent. I think that the red bar will discourage some people from submitting bugs on roundup sites.

dannystaple: are you sure the issue you encountered is the very same issue as the one discussed here?

What is the exact sequence of URLs that you navigated to, and what is the error message that you got? roundup most certainly has a came_from parameter in the login process, so what you ask for should already work.

Please understand that assigning priorities to issues is largely irrelevant. The issue may be deal with today, a year from now, or five years from now - mostly independent of what it's priority is (but issues that we don't consider urgent, as this one, will likely be lowered again in their priority).

Hmm - point taken about the priority, I know how these things can go down.

The initial comment (msg2432) has "If I do a search and do same [log in] from results page, get same error [red background - broken form error]". I've annotated with the square brackets, but this, including the same message, is consistent with what happened to me too.

Ok, to focus the bug: the issue appears that people cannot log in when a search results page is displayed. Login seems to work fine otherwise.