427913 - post_bug.cgi and process-bug.cgi should redirect the browser back to show_bug.cgi?id=nnnnn

Status: RESOLVED WONTFIX

(Bugzilla :: Creating/Changing Bugs, enhancement)

Description

[Zack Weinberg (:zwol)]

It would be nice if process-bug.cgi redirected the browser back to show_bug.cgi?id=nnnn (where nnnn is the id of the bug that was just changed) instead of redisplaying the bug itself.  That way, you could hit reload on that page if you wanted to see whether there had been any updates - right now the browser complains about being asked to reload the result of a POST if you do that.

I don't offhand know how to preserve the little "changes submitted for bug:..." display at the top if you do that, though.  Maybe there is some clever JS trick?

Comment 1

[Max Kanat-Alexander]

This sounds really familiar, I think we already filed it somewhere...?

In any case, yeah, what's important about this is preserving the email notifications, however it's done. The Red Hat Bugzilla currently does this, and sometimes it's slightly annoying when the email notifications matter and I miss them.

Comment 2

[Chris Lawson (gone)]

Well, there's bug 365078, but that's not really the same thing, I don't think. I can't find anything else obviously like this.

I would be all in favour of this too, even if it meant losing the e-mail notification part, because that *very* rarely matters the way Camino and TE use Mozilla's Bugzilla installation. What *does* matter a lot is that session-saving, as implemented in every single browser I'm aware of, cannot restore the results of process-bug.cgi. What you get is the "You apparently didn't choose any bugs to modify" warning when you try to restore those pages, and that's dataloss, and that totally sucks.

What about modifying process-bug.cgi to put the bug number somewhere in the URL? That would give the script something to process without actually modifying the bug, and would be compatible with URL-based session restoration.

cl

Comment 3

[Max Kanat-Alexander]

(In reply to comment #2)
> What about modifying process-bug.cgi to put the bug number somewhere in the
> URL? That would give the script something to process without actually modifying
> the bug, and would be compatible with URL-based session restoration.

  That could totally work. If the POSTDATA was empty, then we would redirect to show_bug.

Comment 4

[Mike Shaver (:shaver emeritus)]

Yes, exactly.  Or bug.cgi could be both "show details" for a GET and "modify bug and return new details" on a POST -- so RESTful!

Comment 5

[Max Kanat-Alexander]

(In reply to comment #4)
> Or bug.cgi could be both "show details" for a GET and "modify
> bug and return new details" on a POST -- so RESTful!

  Oh, believe me, if this wasn't Perl or I had some real web development framework to work with, and I didn't have to preserve backwards-compatibility of URLs, there would be a lot of things different about Bugzilla. :-)

Comment 6

[Jeff Balogh (:jbalogh)]

Preserving notifications like the email during post-redirect-get (hey, it has a wiki page: http://en.wikipedia.org/wiki/Post/Redirect/Get) is sometimes achieved by pushing "messages" into the user's session.  The next page the user goes to will display those messages, but it will be a GET page so everyone will be happy.

Comment 7

[Max Kanat-Alexander]

(In reply to comment #6)
> Preserving notifications like the email during post-redirect-get (hey, it has a
> wiki page: http://en.wikipedia.org/wiki/Post/Redirect/Get) is sometimes
> achieved by pushing "messages" into the user's session.  The next page the user
> goes to will display those messages, but it will be a GET page so everyone will
> be happy.

  Yes, that is the traditional solution, but Bugzilla has no session object in the way that you'd think of it in a traditional web framework, so we have no way to do that, currently. We could add them, but that would involve moving to a web framework (because we're not reinventing that wheel) which we plan to do, but is out of scope for Bugzilla 3.6, so won't be happening for a while.

Comment 9

[Christian Höltje]

The PRG could be implemented as a new cgi -- post_bug_result.cgi -- that would accept a start/stop date and then use that to go through the same steps in Send().

This ties in with bug 301447 -- If the recipient and changeset logic was pulled out, it could be recreated.

The only downside is that it isn't authoritative; it isn't the same data that was used to actually send the email.  :-/

Alternatively, this could be done by just sending the recipients/excluded as cookies or GET arguments.

This would be harder to implement for "change many bugs at once" since there is a limit to the amount of cookies/GET-args.

Comment 11

[David E. Ross]

Because of this bug, I cannot create an Internet shortcut from the report of a newly generated bug.  I can drag from the address area to my desktop and get an Internet shortcut icon, but double-clicking on that icon yields an error.  

Would my problem thus make this a true discrepancy (Importance = Normal) instead of an RFE?

Comment 12

[Mike Shaver (:shaver emeritus)]

Drag the link from the content (the bug number is linked in the redisplay) instead of the thing from the URL bar.

Comment 13

[David E. Ross]

Re comment #12:  That may be a work-around, but it does not resolve my problem.  

Dragging from the address area is supposed to work.  That's how Internet shortcuts are generally created since most Web pages do not contain links to themselves.

Comment 14

[Chris Lawson (gone)]

This also prevents bookmarking the result of a bug submission page. As far as I'm concerned, it's a bug, not an RFE, but I'll let the Bugzilla guys make that call.

cl

Comment 15

[Justin Lebar (not reading bugmail)]

It's not a complete solution, but we're proposing something simple to mitigate most of the effects of this bug in bug 577720.

Comment 17

[Jordan Osete]

About the email notification, I find it more annoying that the person to submit or modify a bug be excluded from the emails sent for this modification. Why not send mail to that person as well ?

(In reply to comment #3)
> (In reply to comment #2)
> > What about modifying process-bug.cgi to put the bug number somewhere in the
> > URL? That would give the script something to process without actually modifying
> > the bug, and would be compatible with URL-based session restoration.
> 
>   That could totally work. If the POSTDATA was empty, then we would redirect to
> show_bug.

This seems a good solution. Do you know if it could be implemented soon ?

Comment 18

[Shawn Wilsher :sdwilsh]

(In reply to comment #17)
> About the email notification, I find it more annoying that the person to submit
> or modify a bug be excluded from the emails sent for this modification. Why not
> send mail to that person as well ?
There is a preference to control that.  It is also not related to this bug ;)

Comment 21

[Frédéric Buclin]

(In reply to Justin Lebar [:jlebar] from comment #15)
> It's not a complete solution, but we're proposing something simple to
> mitigate most of the effects of this bug in bug 577720.

Unless there are still use cases not covered by the implementation of bug 577720 in Bugzilla 4.2rc1, I think this bug can be closed.

Comment 22

[Chris Lawson (gone)]

(In reply to Frédéric Buclin from comment #21)
> (In reply to Justin Lebar [:jlebar] from comment #15)
> > It's not a complete solution, but we're proposing something simple to
> > mitigate most of the effects of this bug in bug 577720.
> 
> Unless there are still use cases not covered by the implementation of bug
> 577720 in Bugzilla 4.2rc1

How about the use-case of "anyone with JS turned off or using a pre-2.0 version of Gecko"? That's probably not an insignificant number of people. In particular, it's a not-insignificant number of Camino developers, and we use Bugzilla *a lot*.

Comment 23

[Frédéric Buclin]

(In reply to Chris Lawson from comment #22)
> How about the use-case of "anyone with JS turned off or using a pre-2.0
> version of Gecko"? That's probably not an insignificant number of people.

At some point, users still using an old browser (or more exactly: an old Gecko) or wanting to browse the web with JS turned off have to accept to not have access to all features a website has to offer. As long as JS is turned on, we can use history.js for old browsers to emulate history.replaceState(), see bug 686422, so that's not an issue.

Comment 24

[Ondra Zizka]

Hello, this is an issue from Creating web apps, Lesson #1.
Could someone please take a look at it, to have it fixed, after 5 years? Please.

Comment 25

[Ondra Zizka]

This was fixed in https://bugzilla.gnome.org/show_bug.cgi?id=595266
Could someone pls take it to the upstream?

Comment 26

[:glob ✱]

(In reply to Ondra Zizka from comment #25)
> This was fixed in https://bugzilla.gnome.org/show_bug.cgi?id=595266
> Could someone pls take it to the upstream?

while there's no patch on that bug, it talks about using javascript to perform history modification, which is what we did in bug 577720.

Comment 27

[Simon Green]

(In reply to Frédéric Buclin from comment #23)
> At some point, users still using an old browser (or more exactly: an old
> Gecko) or wanting to browse the web with JS turned off have to accept to not
> have access to all features a website has to offer.

^ this. All modern browsers now support history.replaceState(), and if you are using a non JS browser (like LWP), then there is no real advantage in showing the 'correct' URL.