+addcomment shouldn't exist

Let's not fix this bug just now, there are more important bugs to fix. Having a separate +addcomment actually makes the code cleaner, and it reduces the risk for double posts (when the user reloads the page after adding the comment).

The URL could exist, but it needn't have a template, right? It could exist only as a redirect back to the bug report page.

This bug is obsoleted by AJAX work.

The page still exists, and still doesn't need to exist, so this bug is still valid.

Why do you think that this page doesn't need to exist? We need a fallback for cases when AJAX doesn't work.

I agree with Tom, and that was really the point of my initial "obsoleted by AJAX" comment and change. I should have been more specific, and like Tom, I think we need to keep this page around now.

2009/9/9 Deryck Hodge <email address hidden>:
> I agree with Tom, and that was really the point of my initial "obsoleted
> by AJAX" comment and change.  I should have been more specific, and like
> Tom, I think we need to keep this page around now.

Also, because ajax is sometimes flaky, it's good to have a fallback as
a workaround. Case in point, editing the description by ajax seems to
fail >50% of the time at the moment.

--
Martin <http://launchpad.net/~mbp/>

Maybe I'm missing something obvious here, but I really don't understand why any of you are mentioning "AJAX". It is not true, and never has been true, that +addcomment is "a fallback for cases when AJAX doesn't work". As a demonstration of this, I am posting this comment without using +addcomment in a browser that has JavaScript turned off completely. And choosing "Add an attachment" goes to +addcomment *regardless* of whether JavaScript is on or off.

What is needed to fix this bug is to move the attachment form from +addcomment to the bug report page. Put it in a collapsed-if-JS-is-on section, if you like, just as the comment form used to be. Then, remove +addcomment. For both comments and attachments, the non-XHR fallback will be POST on the very same forms in the bug report page, just as it is for comments now.

(Martin, the flaky editing of descriptions may be bug 416430.)

On Tue, Sep 29, 2009 at 04:13:39PM -0000, Matthew Paul Thomas wrote:
> Maybe I'm missing something obvious here, but I really don't understand
> why any of you are mentioning "AJAX". It is not true, and never has been
> true, that +addcomment is "a fallback for cases when AJAX doesn't work".
> As a demonstration of this, I am posting this comment without using
> +addcomment in a browser that has JavaScript turned off completely. And
> choosing "Add an attachment" goes to +addcomment *regardless* of whether
> JavaScript is on or off.

You're missing a sane argument for removing +addcomment. What you're
proposing is to add the functionality of +addcomment into the bug page,
which will make the implementation harder. The only downside with having
+addcomment was that the user got an extra redirect, which he actually
would get even if the form POSTed to the bug page anyway, since we
always redirect after a POST.

In short, removing +addcomment wouldn't improve the user experience,
except for on errors (which should be very rare), but it would
complicate the implementation.

The bug description states that there is no benefit from having an
+addocomment page (which is false, there's an implementation benefit),
but it doesn't state that there is a disadvantage of having it.

> What is needed to fix this bug is to move the attachment form from
> +addcomment to the bug report page. Put it in a collapsed-if-JS-is-on
> section, if you like, just as the comment form used to be. Then, remove
> +addcomment.

I agree with what you say here, but this has nothing to do with this
bug. It sounds like you want is to have the attachment form on the bug
page directly. This used to be the case, and this bug predates the
removal of the form from the bug page. (It was removed, to make adding
comments using AJAX easier, since uploading files using AJAX is far from
trivial).

There is a bug for re-adding the attachment form already. If you have
any other arguments for removing +addcomment, please state what the user
experience should be, not what the implementation should look like. The
current (non-JS) user experience is basically:

    1) Post a comment directly from the bug page
    2) Get returned to the bug page after the comment has been posted.

> For both comments and attachments, the non-XHR fallback
> will be POST on the very same forms in the bug report page, just as it
> is for comments now.

The fallback for comments today is to POST to +addcomment; like it
always has been (except for a long time ago, when it was POSTing to the
bug page as you suggested, but we moved this functionality to
+addcomment to make the implementation cleaner). For the user
experience, there is no difference whether the comment it POSTed to the
bug page or to +addcomment, since the user will be redirected to the bug
page in both cases.

To clarify, I don't think this bug has been obsoleted with AJAX, but I do agree that Won't Fix is the right status here, since it's about making the implementation more complicated, without improving the user experience very much. (And this bug is so old, so that the UI has changed too much for this bug to apply to the UI).

Ok, that makes more sense than the Ajax explanation, thank you. :-) If the +addcomment URL becomes used only for POST and redirects straight back to the bug report page, that still would not require +addcomment to return a page of its own on GET, but I accept that it's probably easier for the URL to exist with an associated GET page than without. (IIRC another reason for introducing the redirect, besides simplifying the implementation, was to prevent double-posting when reloading the page manually after posting a comment.)

My original concern, which I should have described explicitly, was +addcomment cluttering up browser histories and URL auto-complete menus etc when you try to revisit bug reports. As you alluded to, fixing bug 381561 will address that. Sorry for the annoyance.