Bug 803961

Created attachment 570496 [details]
  --> https://bugzilla.redhat.com/attachment.cgi?id=570496
png file to test.

I've hit this bug today when I cloned bug #717069 into bug #842228. I wanted to attach a patch during bug creation, but the file was missing after bug #842228 had been created.

Reproduces 100% for me when attaching file to publicly accessible BZ, there is message:
"We were unable to store the file you uploaded because of incomplete information in the form you just submitted. Because we are unable to retain the file between form submissions, you must re-attach the file in addition to completing the remaining missing information above.

Please re-attach the file engine.log.1 in the field below:" 
when confirming that bugzilla is public. There is need to select the same file again as it was done in previous step, therefore user must select same file twice.

(In reply to comment #3)
> "Because we are unable to retain
> the file between form submissions, you must re-attach the file in addition
> to completing the remaining missing information above.

As per the above, this is a limitation on the way that HTTP file uploads work.

  -- simon

(In reply to comment #3)
> Please re-attach the file engine.log.1 in the field below:" 

Apparently it remembers the file, why can't it re-attach it itself? If group is selected, there is no need to choose the same file twice. Description and all other stuff is not required to fill in again - I don't see the difference.

(In reply to comment #5)
> (In reply to comment #3)
> > Please re-attach the file engine.log.1 in the field below:" 
> 
> Apparently it remembers the file, why can't it re-attach it itself? 

The HTTP protocol (and browser security) doesn't allow the file to be automatically attached again.

> If group
> is selected, there is no need to choose the same file twice. Description and
> all other stuff is not required to fill in again - I don't see the
> difference.

The difference is the way that browser send form information to web servers. All the non-file fields are stored as <input type="hidden"> attributes. Unfortunately, this cannot happen with files.

  -- simon

It IS a bug. And highly annoying one.
I wonder how many useful attachment have we lost thanks to this NOTABUG?

I was just pinged because of a missing stack trace I had stored in temp space and intended to delete after submitting Bug. Fortunately I have not done so.

As this may be causing loss of important data I would love to see it fixed.

Could we have the attach file disabled at bug create page then?
Or when a file is submitted have the *** confirm page ask for it again?
Or have other mechanism how to prevent loss of data?

Perhaps it did warn me, but who reads warnings?

As we are already used to the confirm public bug page, no one cares about its content and just goes [Next] [Next] [Next] (bad habit from having to confirm every step...)

Or do we need just get used to it?

I am not able to reproduce this bug (tried both here and on partner-bugzilla).  

To make any progress with this bug we need a test procedure that reliably reproduces the problem.  It is possible that the problem depends upon one or more particular field values entered when filing a bug (e.g. Bugzilla has some attributes that are specific to certain Products and Components), so please include all non-default field values in the procedure.

To avoid polluting the live database with test bugs, you can use https://partner-bugzilla.redhat.com/enter_bug.cgi to experiment.

I've had this happen when the attachment description was left blank.

The description is a required field, so I expect Bugzilla is removing the attachment as it is not correctly filled out.

(In reply to Matt Tyson from comment #10)
> I've had this happen when the attachment description was left blank.
> 
> The description is a required field, so I expect Bugzilla is removing the
> attachment as it is not correctly filled out.

After investigating further, I can see two separate problems:

1. As Matt points out, an empty description causes an attachment to be lost, but only if the attachment is text rather than a file (i.e. you click the "paste text as an attachment" link).  I have filed that bug upstream as https://bugzilla.mozilla.org/show_bug.cgi?id=1061423.

2. As hinted in Comment #3, a file attachment needs to be added a second time if the user encounters the "Confirm publically accessible bug" warning page.  In that scenario, it is too easy for the user to ignore the warning and just click Create Bug, which causes the attachment to be lost.

I propose that initially we change the "Confirm publically accessible bug" page so that the user must either attach their file again or explicitly decline to do so (via a button or checkbox) before they can submit their new bug.


A more advanced solution we could consider a little further into the future would be to avoid having to attach the file a second time by accepting the attachment the first time as "pending" and deleting it from the database after a suitable time (e.g. 24 hours) if the user doesn't end up creating the bug.

That would represent a significant deviation from the upstream code however, and wouldn't be appropriate for upstream as they don't have the "Confirm publically accessible bug" page, and thus have no use-cases where an attachment has to be attached twice.

Note: the estimate only covers the initial solution proposed above, not the advanced solution.

The "Confirm publicly accessible bug" screen was removed in version 4.4.9039, which was deployed on 20 September 2015.  That cures item 2 above, leaving only item 1, which is covered by upstream bug https://bugzilla.mozilla.org/show_bug.cgi?id=1061423.