Bug 803961 - Attachment got lost when attaching it during bug creation
Attachment got lost when attaching it during bug creation
Status: CLOSED UPSTREAM
Product: Bugzilla
Classification: Community
Component: Creating/Changing Bugs (Show other bugs)
devel
Unspecified Unspecified
medium Severity medium (vote)
: ---
: ---
Assigned To: PnT DevOps Devs
tools-bugs
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-03-16 02:21 EDT by Chao Yang
Modified: 2016-08-16 01:09 EDT (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-09-25 02:51:52 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
png file to test. (130.86 KB, image/png)
2012-03-16 02:21 EDT, Chao Yang
no flags Details

  None (edit)
Description Chao Yang 2012-03-16 02:21:38 EDT
Created attachment 570496 [details]
png file to test.

Description of problem:
When I reported a bug to bugzilla, I had attach a png picture to it. But after the bug was created, the attachment got lost.

Version-Release number of selected component (if applicable):
Current bugzilla.

How reproducible:
1/1

Steps to Reproduce:
1.create a bug
2.attach a png picture to it
3.
  
Actual results:
The picture was lost. 

Expected results:
The attachment is there.

Additional info:
1. BZ803957 is the one I mentioned above.
2. The png picture can be attached after the bug has been created.
3. I have attached the same picture in this bug. If we can not see it, Then we know it's a bug for bugzilla.
Comment 1 Simon Green 2012-03-16 02:40:24 EDT
Created attachment 570496 [details]
  --> https://bugzilla.redhat.com/attachment.cgi?id=570496
png file to test.
Comment 2 Honza Horak 2012-07-23 04:39:46 EDT
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.
Comment 3 Jakub Libosvar 2012-10-10 07:49:38 EDT
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.
Comment 4 Simon Green 2012-10-10 19:01:28 EDT
(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
Comment 5 Jakub Libosvar 2012-10-11 02:22:52 EDT
(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.
Comment 6 Simon Green 2012-10-11 02:32:09 EDT
(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
Comment 7 Marian Csontos 2014-08-01 08:56:56 EDT
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?
Comment 8 Marian Csontos 2014-08-01 09:01:15 EDT
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?
Comment 9 Jason McDonald 2014-09-01 00:15:54 EDT
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.
Comment 10 Matt Tyson 2014-09-01 21:30:08 EDT
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.
Comment 11 Jason McDonald 2014-09-02 01:56:19 EDT
(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.
Comment 12 Jason McDonald 2014-09-02 01:57:45 EDT
Note: the estimate only covers the initial solution proposed above, not the advanced solution.
Comment 13 Jason McDonald 2015-09-25 02:51:52 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.