Comment 9 for bug 2755

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.