This is 1/2 of the original problem described in bug 87404. Basically, if you lose your login (or you don't have cookies enabled) when creating an attachment, the file is lost when you have to log in again, spitting a somewhat cryptic error message.
FWIW, I think the solution described in bug 87404 comment 21 is probably the best way to go with this, if we can make it work.
Severity: minor → normal
(In reply to comment #1) > FWIW, I think the solution described in bug 87404 comment 21 is probably the > best way to go with this, if we can make it work. Read comment 57 on how to do this
I'm still partial to the solution in bug 87404 comment 30. Our current solution for user matching (what this got split off of) is less-than-optimal also, since it discards the requestee field if a match has to be made, and that would let us put that back without requiring AJAX for it to function (although that would certainly be cool, too).
*** Bug 303274 has been marked as a duplicate of this bug. ***
*** Bug 326451 has been marked as a duplicate of this bug. ***
(In reply to comment #0) > spitting > a somewhat cryptic error message. In the interim, could a less cryptic message be spat to the user, to minimize e-mails to the sysadmins?
(In reply to comment #0) > spitting a somewhat cryptic error message. (making sure that people can find this bug through search engines) The cryptic message in question is usually something like: undef error - Undefined subroutine Fh::slice at data/template/template/en/default/global/hidden-fields.html.tmpl
Summary: Attachments don't work if you need to log in again → Attachments don't work if you need to log in again [ Undefined subroutine @ Fh::slice ]
This definitely won't go into 3.0--it's a major architectural change.
Flags: blocking3.0? → blocking3.0-
We need to fix this so the error doesn't happen (and give an error explaining what happened instead of choking on it) at a minimum before 3.0. Fixing it the right way can be an architectural change.
Flags: blocking3.0- → blocking3.0+
For reference I get two or three emails a week on bugzilla-admin reporting this error on bmo, even after the upgrade. I'd gotten the impression somewhere that the filehandle leaking into the hidden fields template had gotten resolved already, but apparently it hasn't. I thought we dealt with this by discarding the flag usermatches and telling the user they'll have to redo their requests...
This has nothing to do with flags. When you have to log in, you get an intermediate page, and the attachment cannot be saved as a hidden field.
Target Milestone: --- → Bugzilla 3.0
This is really about having to show an intermediate page of any sort (rather than needing to log in) when adding an attachment, right? I was certainly logged-in when I encountered the situation I filed bug 365156 about (and the issue there was needing username matching on the cc field, not any attachment-related field per se)....
This doesn't really sound like the same bug to me, but reed asked me to log it here. I just tried to create a new bug and attach a patch in one step. I got the following error message: URL: https://bugzilla.mozilla.org/post_bug.cgi undef error - Undefined subroutine Fh::slice at /opt/webtools/bugzilla/data/template//opt/webtools/bugzilla/template/en/default/global/hidden-fields.html.tmpl line 58 Note the duplicate path in the error message. I was logged in when I attempted to file the bug, and the footer below the error message confirms that I'm still logged in.
confirming everything in comment 15. I suspect cc caused it - I had cc entries that were not full addresses and should have gotten bz address completion screen. So Smokey might be right about "any intermediate" screen.
Created attachment 250711 [details] [diff] [review] patch, v1 As per my discussion with justdave on IRC, we will ask the user to re-attach the file in the intermediate page, explaining why he has to do so. This is an intermediate solution between throwing an error and having the attachment stored in a temporary table in the DB (which would involve a DB schema change, which we want to avoid so close to 3.0 RC1).
Assignee: attach-and-request → LpSolit
Status: NEW → ASSIGNED
Attachment #250711 - Flags: review?(justdave)
might want to adjust the message "incomplete information in the form you just submitted" - it tends to sound like the user caused the error
Attachment #250711 - Flags: review?(justdave) → review+
Checking in skins/standard/global.css; /cvsroot/mozilla/webtools/bugzilla/skins/standard/global.css,v <-- global.css new revision: 1.30; previous revision: 1.29 done Checking in template/en/default/account/auth/login.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/account/auth/login.html.tmpl,v <-- login.html.tmpl new revision: 1.18; previous revision: 1.17 done Checking in template/en/default/bug/create/confirm-create-dupe.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/bug/create/confirm-create-dupe.html.tmpl,v <-- confirm-create-dupe.html.tmpl new revision: 1.3; previous revision: 1.2 done Checking in template/en/default/global/confirm-user-match.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/global/confirm-user-match.html.tmpl,v <-- confirm-user-match.html.tmpl new revision: 1.16; previous revision: 1.15 done Checking in template/en/default/global/hidden-fields.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/global/hidden-fields.html.tmpl,v <-- hidden-fields.html.tmpl new revision: 1.10; previous revision: 1.9 done
Status: ASSIGNED → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.